32

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.

Sebastian Celis
  • 12,185
  • 6
  • 36
  • 44

4 Answers4

52

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 (e.g. --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.

Sebastian Celis
  • 12,185
  • 6
  • 36
  • 44
Paul Wagland
  • 27,756
  • 10
  • 52
  • 74
  • 3
    svn.pushmergeinfo is indeed a godsend since it allows almost-painless merging in Git and then dcommitting back to SVN. However, in the current version (1.7.8) it has a bug when reintegrating an SVN branch back to trunk with Git. See my question about it here: http://stackoverflow.com/questions/9700998/git-svn-with-svn-pushmergeinfo-how-to-avoid-self-referencing-mergeinfo-lines – Avish Mar 14 '12 at 11:27
12

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.

Dr. Mike Hopper
  • 802
  • 1
  • 8
  • 19
  • 10
    The long answer is inaccurate for recent versions of SVN (1.5+). SVN _does_ differentiate between refactorings and branching exactly via `svn:mergeinfo` property. There are edge cases where it may not work, but that's not the reason why basic branch/merge couldn't be supported. – Kornel Mar 22 '10 at 11:37
  • 2
    Like I said, svn:mergeinfo is a band-aid. Svn will always be weak in the area of branching until it has a dedicated "branch" command. I suffered through countless hours using SVN 1.5 and having to manually remove bogus mergeinfo property data when merging changes from hundreds of files across multiple branches. SVN just doesn't have enough information in its metadata to make the right decisions. Usually we got merge conflicts even when there really wasn't a conflict. Git is so much easier and more powerful! – Dr. Mike Hopper Mar 29 '10 at 21:52
  • Exactly. I can't tell how happy I am after moving my project to git. The countless hours spent on resolving svn conflicts are no longer there - we now spend time on resolving conflicts that really make sense. – yclian Apr 05 '10 at 01:14
6

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

Marius K
  • 498
  • 5
  • 6
1

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 (e.g 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.

Community
  • 1
  • 1
vadishev
  • 2,979
  • 20
  • 28
  • Doesn't seem strictly like an answer to the question asked. Please be sure to read the [FAQ on Self-Promotion](http://stackoverflow.com/faq#promotion) carefully. Also note that it is *required* that you post a disclaimer every time you link to your own site/product. You have a number of good answers, so it's clear you aren't here for spamming, but just note that the community can tend to react negatively to too much self-promotion here. – Andrew Barber Sep 10 '12 at 18:11
  • Andrew Barber, thanks for the heads-up. I've updated my answer to make it more relevant. – vadishev Sep 10 '12 at 20:35
  • As a user of subgit and having no vested interest in it, I would like to add that that whereas I see git-svn as a toolkit containing some of the parts you could use to cobble together some kind of git <-> svn bridge, subgit is a finished and working bidirectional git <-> svn bridge. If you use git and svn in a fairly standard way, subgit needs very little additional work. As vadishev says, git and SVN have very different models but the subgit team have done a really good job of resolving most of the differences. – Andy Sep 12 '17 at 10:00