git-svn可以正确填充svn：mergeinfo属性吗？

Question

I am evaluating git-svn and trying to determine how well it will play with a particular svn repository. I am mostly concerned with getting git-svn to perform merges in such a way that the svn:mergeinfo property is correctly set in the subversion repo. Is this possible?

Here is what I have done so far:

# Checkout the SVN repo.
$ git svn clone svn://server/project1 -T trunk -b branches -t tags

# Make sure we are working on trunk.
$ git reset --hard remotes/trunk

# Modify the working copy.
$ vim file.txt

# Commit locally to the git repo.
$ git commit -a

# Push the commits back to the SVN server.
$ git svn dcommit
Committing to svn://server/project1/trunk ...
    M   file.txt
Committed r178
    M   file.txt
r178 = b6e4a3a0c28e7b9aa71d8058d96dcfe7c8a2b349 (trunk)

Now how would I go about merging that particular commit into one of the subversion branches? Again, it is very important to me that git properly set the svn:mergeinfo property when committing the change.

Answer 1

Even though this is an old question, the current state of affairs with git-svn has changed since it was asked. Specifically, in git 1.7.5, there is some limited support for setting the svn:mergeinfo when dcommitting back to svn.

git svn dcommit now accepts the -mergeinfo=<mergeinfo> flag. To quote from the 1.7.5+ man page :

-mergeinfo=<mergeinfo>

Add the given merge information during the dcommit (eg --mergeinfo="/branches/foo:1-10"). All svn server versions can store this information (as a property), and svn clients starting from version 1.5 can make use of it. git svn currently does not use it and does not set it automatically.

One should be very careful when using this though. Even though the man page says "add" what it really means is "replace". That is, the svn:mergeinfo attribute is set based on what is passed, it does not add the specified revisions to the already existing svn:mergeinfo . Learn from my mistake…

Edit:

It appears that they are still working on improving this even further. As of git-svn 1.7.7 , the following text was added to the git-svn man page:

config key: svn.pushmergeinfo

This option will cause git-svn to attempt to automatically populate the svn:mergeinfo property in the SVN repository when possible. Currently, this can only be done when dcommitting non-fast-forward merges where all parents but the first have already been pushed into SVN.

Answer 2

Short answer: No, git-svn does not care about svn:mergeinfo properties since git-svn is not doing merges back to svn (it is doing commits).

Long answer: Most people use git-svn to get out of the brain-damaged merging of svn. The problem with svn is that it does not differentiate between copying files or folders (often caused by refactoring) and creating a branch since creating a branch or tag is done by using the "svn copy" command. The svn:mergeinfo property is a band-aid on this problem but there are still cases where modifications are ambiguous. Git has much more robust support for branching and merging.

Answer 3

Seems like they are working on it. It might be possible in next version:

http://git.kernel.org/?p=git/git.git;a=commit;h=6abd9332f97441a568421ba233ad8929b50a7efc

Answer 4

Theoretical part

The problem is that Subversion and Git have significantly different merge tracking mechanics.

As result certain merge information can not be properly translated from Subversion to Git. For instance, Git does not track cherry-picks at all, when SVN tracks them even on subdirectories level.

On the other hand there are no problems representing Git merge history in Subversion. But be careful here, as some SVN file/directory properties are not present in Git repository (eg svn:keywords), modifications of these properties are lost in SVN repository once you dcommit a merge commit.

Practical part

git-svn does not automatically set svn:mergeinfo property according to all the parents of Git commit. But you can specify the value of the property manually before dcommitting corresponding commit.

Have a look at SubGit , a server-side replacement for git-svn. It translates merge information in both directions when it's possible. It also supports such SVN properties as svn:ignore, svn:eol-style and svn:mime-type.

For more details please refer to SubGit documentation and SubGit vs. git-svn comparison.

SubGit is a commercial product with free options for open-source, academic and small projects. And I'm one of SubGit developers.