On Fri, Jul 22, 2011 at 01:01:06PM -0500, Les Mikesell wrote: > We have some cases of (very) remote teams working out of the main > repository and some where the live project repository is near the > remote group and svnsync is used to pull a copy back to headquarters > for a backup and some of the builds. The tradeoffs are fairly > obvious but the remote repository was set up when network > connectivity was not very good - I'm not sure we'd do it again under > better conditions. > > I'm kind of curious about how git-svn would work out for this kind of use.
I would not recommend git-svn as an alternative to write-through proxying in most environments, for the reasons below. A big limitation of git-svn is that it does not compute svn:mergeinfo when merging Subversion branches. In Subversion's terms, you can only update and commit safely, but not merge safely. You can branch and merge locally in git, but all the git branches you create in the git repository cloned from svn usually map to one Subversion branch. If they don't then you need to add merges between branches to svn:mergeinfo when you push revisions to Subversion. This is possible with recent git-svn versions, but you have to manually pass the correct svn:mergeinfo value (the *full* value, not just the modifications your merge is creating!). If your server is older than 1.6.17, syntactically incorrect mergeinfo passed to git-svn can severely damage the repository, see http://subversion.tigris.org/issues/show_bug.cgi?id=3895 and http://subversion.tigris.org/issues/show_bug.cgi?id=3896 The above are of course bugs in Subversion, not git-svn. But manually computed mergeinfo can still be wrong even if it is syntactically correct. And you can push commits in the wrong order, i.e. make some changes locally to branch 'foo', push a revision into Subversion that reintegrates branch 'foo' (including your local changes which aren't in Subversion yet), and then push more revisions that add the local changes to branch 'foo'. So I would not recommended git-svn as a drop-in Subversion client at this point, unless you can trust git-svn users to compute svn:mergeinfo as reliably as the standard 'svn' client would and be careful not to create history that looks ridiculous in Subversion. If your use of git-svn does not involve merging between Subversion branches it is probably safe. But a write-through proxy setup has none of these problems.
