How much of the power of git is lost by using git-svn and a shared subversion mainline?

Question

I'm evaluating various options for getting our team away from CVS. We have another large team on another site using Subversion, and some of our developers work with the Subversion server. Therefore, Subversion is an obvious choice for our team. However:

1. Operations involving the Subversion server can be coffee-break slow (although we have a good connection between sites).
2. Many of us our sold on the idea of distributed version control, and use Mercurial or git extensively (and then merge and commit to CVS and grab changes from

git-svn looks interesting but what I'd like to know is how much of the power of a DVCS such as git is lost by having a handful of centralised branches in Subversion. In particular, I'd still like to be able to keep the kind of workflow we have with Mercurial, such as:

1. Can we pull the repositories of other team members and merge, and thus collaborate on feature branches before they go to our main stable trunk on Subversion?
2. Can we expect the wealth of trickery possible with git to generally work, or do we need to be careful to avoid confusing git-svn?
3. Can we use git to speed up checkouts from Subversion by pulling it across the connection from the other site once and then pulling it into individual repositories once.
4. If someone commits to Subversion, can we arrange that other git users via git-svn still see the full development history?
5. Can we basically avoid having to wait for interactive operations on the Subversion server despite it having half a world of latency?

Many of us are used to the idea of a main fairly stable shared branch with a simple linear history which everyone can push to, and so they merge to the tip regularly. It isn't clear to me how to support this work flow well with git (or Mercurial or Bazaar).

Answer 1

For what I've seen, you can use git between repository retrieve with git-svn (so you could have a git public repository which would be the "mirror" of the svn repo you're talking about, but the git repo could be hosted in you site).

Thus checkout/clone/push/pull for git users will be fast. Then I guess you can add hooks to your git repo to sync with the svn repo via git-svn, but you'll have to deal with conflict until you use different branches.

What we do here is that every dev has a branch with his name in it and he has to merge with master branch (so he's handling the conflict) before an admin merges his branch with the master, without any conflict since the dev already handle it.

Hope this help.

Answer 2

You do lose a lot, and it feels kind of second class, but you do gain all the wonderful branching stuff.

I learned git by using it to work on a project that was hosted in subversion. git allowed me to do all my local development and make quite a bit of progress on the project while still tracking the mainstream branch and even sharing my work with others.

In the end, we ended up pushing the whole project to git because of all of the information that was lost when going to subversion.

What you lose:

1. Merge tracking -- sort of.
2. Proper recording of the authorship of changes.

I say "sort of" WRT #1 because if you keep one tree together, it'll track the merges and stuff that you did with git and applied to subversion, but once you try to clone that repo, or someone else does a git-svn clone, you lose that and merges get really painful again.

The authorship stuff matters a lot to me, because I find it very important to make sure people get credit for the work they do.