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.
Received on 2011-07-23 11:52:58 CEST