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

From: Thomas Ferris Nicolaisen <tfnico@gmail.com>
Date: Apr 30, 2011, 23:08 UTC
Message-ID: <BANLkTinEgDSFsOj2uY-2WdridoD1ZhQQKw@mail.gmail.com>
In-Reply-To: <1304096029355-6317576.post@n2.nabble.com>

On Fri, Apr 29, 2011 at 6:53 PM, ryanzec <basire@gmail.com> wrote:

Show 8 quoted lines

> 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).