Sam Vilain wrote:
If svn is still the master there should be no difference to the way you normally collaborate development using Subversion. The central server is still the publishing point for trunk, however many release engineering branches you use, and feature branches. It's only if you want to start mixing groups of people, some working with subversion, and other people using git-svn and merging between each other at the git level, that you can start getting confused. They can safely operate at the patch trading level though.
I can vouch for all of that as well. On some of my repositories I use git solely as a fancy Subversion client, no interaction with any other git repositories. And hardly anyone at my company even knows about it; as far as they are concerned I just check stuff into the svn repository like any other engineer.
But on a few of my repositories I do things like use git to keep a copy of my work in progress synced up between my laptop and my development server, or (rarely) share my work with another git-aware developer. In those cases I do have to be kind of careful what I do, mostly around making sure all the repositories are in agreement about which branches come from where and about when I use rebase vs. merge vs. squash merge.
I will say, though, that the upcoming addition to git-svn to allow merges to be directly committed to the svn repository will make some of those kinds of scenarios a lot less brittle than they are now. It's still a work in progress but it looks very promising so far. (Search the list for "[PATCH] git-svn: allow dcommit to retain local merge information" if you want to see what I'm talking about.)
-Steve - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
