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 > 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. > 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. > - 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html