Re: What Features Do I loose With git-svn?

[Thomas Ferris Nicolaisen <tfnico@gmail.com>]

On Fri, Apr 29, 2011 at 6:53 PM, ryanzec <basire@gmail.com> wrote:
> I want to use git for a project I am working on however because the project
> is going to possibility have a lot of binary content in size and number of
> files (game project), it is probably going to be hard to convince my team to
> make the switch since I have no real solution besides just use git for the
> code and svn for the binary data.  I am hoping git-svn will do the trick for
> me.  The question is are they any features I loose (like cherry picking) or
> anything that I have to look out for (does updating from svn cause merging
> issues just like working all in SVN does).

Subversion does not grok the semantics of a merge. That means that if
you merge in a branch and do an svn dcommit, the svn log will only
contain the commit message of the merge-commit, and have no trace of
the commits that took place out in the branch.

The tidiest way around this is generally to keep history linear, and
avoid merging by doing rebasing instead.

Have a look at the screencast here, it should explain it pretty well:
http://blog.tfnico.com/2010/10/gitsvn-4-collaborate-with-other-git.html

You can still cherry pick. Actually, cherry-picking has served me very
well for doing traditional SVN "merges" (copying a commit from one
branch to the other, instead of that clunky svn merge -c R url .
stuff).