Q: workflows when tied back to git-svn

Q: workflows when tied back to git-svn

[Nigel Magnay]

Hi list;

We have a number of projects which currently are mastered in a
centralised svn repo, and it makes use of svn:externals. It's becoming
increasingly apparent (finally) that everyone working in the various
project /trunks is not working, and what's really required is a number
of branches. Also that the git submodule approach is superior (for our
needs) to svn:externals.

Now ideally, I could swap us all over to git; I've been using git-svn
for a while and it works very nicely (modulo not noticing the
requirement to merge with --squash, which is obvious once you know!).
How-ev-er.. the natives are revolting.. some people didn't even want
to move to SVN from CVS let alone a new tool. Alas some people just
don't like change.

I'm guessing I can give teams their branches in svn, and manage the
merging back with git and git-svn - that way I'll retain some kind of
sanity in repeated merging. For those devs with the right fu can start
using git directly, and we slowly start deprecating the whole svn
infrastructure a bit at a time.

Anyone got any experiences of doing this (particularly things to note,
like the --squash thing that might trip us up, or workflows)? I've
never tried dcommitting back to anything other than trunk..

Secondly (slightly related) - because of our svn:externals usage, we
tend to have a lot of repeated repo checkouts. I'm *assuming* that If
I've got 2 git modules that have the same submodules (e.g
A
  mod1
  mod2

B
 mod1
 mod2

Then it's 'safe' to make the mod1 and mod2 directories symlinks to the
same directory?