Re: GSOC Proposal draft: git-remote-svn

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Apr 2, 2012, 11:00 UTC
Message-ID: <CALkWK0nYhfPQrwrrnGP21za6CkryuzfV+ki+WKUdtA1BaLHTsA@mail.gmail.com>
In-Reply-To: <2487557.B8qfnaixh3@flomedio>

Hi Florian,

Florian Achleitner wrote:

> - svn commits are only possible after updating the working copy first, i.e.
> fetching and merging new revisions on the server. This is like implicitly
> rebasing your local work on the remote head before pushing to an svn
> repository.

This shouldn't worry you, because we don't have a Git -> SVN converter yet. However, I have written a prototype svn-fi. Unfortunately, due to the way marks work in fast-import, svn-fi is far from complete.

See: https://github.com/artagnon/git/tree/svn-fi

Show 9 quoted lines

> Branches exist due to the convention of having branches/, trunk/, and tags/
> directories in a repository, so do tags. But this is not mandatory and
> therefore there are many different layouts. It follows that in svn it is also
> possible to commit across branches. This means that a single commit can change
> files on more than one branch (accidentally or deliberately).
> To convert svn branches to git we have to detect branch semantics by examining
> the svn tree's structure and it's metadata (it has a 'copyfrom' property).
> Previous efforts show that this will not be possible fully automatically
> without configuration and interaction with the user.

See also: http://article.gmane.org/gmane.comp.version-control.git/150007

> "esr" developed a tool to manipulate and export subversion repositories [7]
> that should be able to detect branches, but it's sources are not available
> yet.

Sources are available at git://gitorious.org/reposurgeon/reposurgeon.git Do let us know how SBL compares to reposurgeon. Personally, I like the idea of a standard "language" to express the mapping.

> In git's source tree we have a vcs-svn/, a set of functions to convert svn
> dumps to git-fast-import streams. Those are used by svn-fe to one-way import
> svn history to git. svn-fe doesn't do branch mapping yet.

Are you planning to extend svn-fe to do the mapping, write it as a separate program, or write it into the remote helper? I personally don't mind if the mapping is done in Perl (like in git-svn or SBL) as opposed to C; mapping is just parse-intensive.

Show 6 quoted lines

> 1. Write a new bi-directional remote helper in C.
> [...]
>  - It reads a configuration file containing branch mappings according to [6].
> These mapping have to be pre-generated using tools developed along with the
> language. The remote helper has no way of asking the user what to do. It will
> fail if a mapping is unclear.

Right.

>  - Because generating the branch mapping configuration already requires that
> you have a dump of the svn repo, the helper should probably be able to read
> from a file in place of svnrdump too.

You can clone the SVN dumpstream from svnrdump using tee (or similar), sending one copy to svn-fe and another to the SBL configuration generator.

Show 5 quoted lines

>  - Using the config the helper translates svn branches/tags to git
> branches/tags and converts other metadata as applicable. It probably has to
> store some information about the mapping in a file in .git to allow a
> reconstruction on subsequent invocations. I think this is especially important
> when pushing to branches (does it already exist in svn, and where? is it new).

How will the actual mapping be done? Using filter-branch's subdirectory filter, or something else?

> 3. Add output capabilities to vcs-svn. Currently the code in vcs-svn can only
> convert svn to git. To push to svn we also need conversion and mapping from
> git to svn. The actual mapping code for branches should also be placed here
> {??} and called by the remote helper.

I think this bit sounds overtly ambitious. I think if you can build a seamless one-way SVN -> Git bridge in one summer, it'll be quite an achievement in itself. Finishing and getting svn-fi merged should be last priority; I'll try to work on it myself in summer.

Ram