What Features Do I loose With git-svn?

What Features Do I loose With git-svn?

[ryanzec]

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).  Right now the only things I know
to look out for is:

<ul>
<li>Instead of git pull/push I have to use the git-svn equivalents</li>
<li>If I have changes that are not in the index and I need to pull the
latest code form SVN, I have to stash first, update from svn, and then apply
the stash back.</li>
</ul>

Any other things I have to look out for?  I am mainly concerned that using
git-svn will re-introduce the merge issues of SVN the git is great at doing.--
View this message in context: http://git.661346.n2.nabble.com/What-Features-Do-I-loose-With-git-svn-tp6317576p6317576.html
Sent from the git mailing list archive at Nabble.com.

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

[Motiejus Jakštys]

On Fri, Apr 29, 2011 at 09:53:49AM -0700, ryanzec 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).  Right now the only things I know
> to look out for is:
> 
> <ul>
> <li>Instead of git pull/push I have to use the git-svn equivalents</li>
> <li>If I have changes that are not in the index and I need to pull the
> latest code form SVN, I have to stash first, update from svn, and then apply
> the stash back.</li>
> </ul>
This list does not support HTML. Thankfully. :)

> 
> Any other things I have to look out for?  I am mainly concerned that using
> git-svn will re-introduce the merge issues of SVN the git is great at doing.--
I never tried merging of "SVN" branches. What I used to do is check-out
my local branch from tip of master (svn upstream), work on it. Before
"merging" changes upstream I rebased on top of upstream again, got a
fast-forward, and pushed to SVN.

If you used git-svn, why would you "merge"? As it does not support
"reverting" (at least I'm unaware of it), it's quite unnecessary IMHO
(put your merge commits upstream).

Motiejus

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

[Thomas Ferris Nicolaisen]

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