Menu
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.
455
git-svn is a specialized tool for Git users to interact with Git repositories. It works by providing a Git frontend to an SVN backend. With git-svn, you use Git commands on the local repository, so it's just like using normal Git. However, behind the scenes, the relevant SVN commands are sent to the server.
git svn is a git command that allows using git to interact with Subversion repositories. git svn is part of git, meaning that is NOT a plugin but actually bundled with your git installation. SourceTree also happens to support this command so you can use it with your usual workflow.
SVN has one central repository – which makes it easier for managers to have more of a top down approach to control, security, permissions, mirrors and dumps. Additionally, many say SVN is easier to use than Git. For example, it is easier to create a new feature. With Git, it takes an extra step to create a new feature.
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…
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.
74
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.
42
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
