Need for a local Subversion server?

[Phil Montgomery <ph...@gmail.com>]

I have a question regarding the need of a subversion mirror server.

Our work is done on UNIX systems.  We currently have a master repository in
England.  We mirror it as a read only repository to the states.  The system
that acts as the Subversion server in the states is rather old and its
faster to do checkouts from the remote repository then the local one.  I’m
curious why we even need a local subversion server.  We cannot add anything
to the local repository.  Developers check out the code, update the files in
their working directory, then commit them to the remote server.



Now trying to commit, resolve conflicts, and merges are another matter.
Latency has a far greater impact on those tasks.  We often thought about
making a post-hook on the commit to initiate syncs from the master to the
remote site in order to do the conflict resolution locally, allowing our
developers to use a GUI interface or type in their xterm and not wait for
the characters to appear.  We have yet to do that test to see if it would
help.



(We did try the WanDisco Enterprise solution and like it, but in a spending
freeze so absolutely no funds for that product)

I do appreciate your time and any constructive responses. :)

phil

Re: Need for a local Subversion server?

[Stefan Sperling <st...@elego.de>]

On Fri, Jul 22, 2011 at 10:12:31AM -0700, Phil Montgomery wrote:
> I have a question regarding the need of a subversion mirror server.
> 
> Our work is done on UNIX systems.  We currently have a master repository in
> England.  We mirror it as a read only repository to the states.  The system
> that acts as the Subversion server in the states is rather old and its
> faster to do checkouts from the remote repository then the local one.  I?m
> curious why we even need a local subversion server.  We cannot add anything
> to the local repository.  Developers check out the code, update the files in
> their working directory, then commit them to the remote server.
> 
>
> Now trying to commit, resolve conflicts, and merges are another matter.
> Latency has a far greater impact on those tasks.  We often thought about
> making a post-hook on the commit to initiate syncs from the master to the
> remote site in order to do the conflict resolution locally, allowing our
> developers to use a GUI interface or type in their xterm and not wait for
> the characters to appear.  We have yet to do that test to see if it would
> help.

Have you considered using a write-through proxy setup?
See http://svnbook.red-bean.com/nightly/en/svn.serverconfig.httpd.html
 
> (We did try the WanDisco Enterprise solution and like it, but in a spending
> freeze so absolutely no funds for that product)

The write-though proxy feature that ships with Subversion provides
similar advantages. The only major difference is that write operations
are proxied through to the master server, and must be copied back to
the slave server. So there is a time window where the slave isn't
up-to-date. It still provides major advantages for read-only operations,
and this speeds up lots of things, including merges. Basically, anything
but commit operations can be answered from the local server so there
is little latency.

The subversion project itself uses this type of setup with the
Apache Software Foundation's Subversion server, where our own
code is hosted. There is one server in the US (which acts as the
master server) and one in Europe (which acts as the slave).
svn.apache.org resolves to a different address depending on location.

Re: Need for a local Subversion server?

[Andreas Krey <a....@gmx.de>]

On Fri, 22 Jul 2011 13:01:06 +0000, Les Mikesell wrote:
...
> I'm kind of curious about how git-svn would work out for this kind of use.

I'd say that pretty much depends on your round-trip time. The initial
'git svn clone' can take seriously long; I did one for a repo that
yields 328 commits in 450 seconds, over a consumer DSL line (via http
portforwarded via ssh). The regular operations will take about as long as
ther native svn counterparts, except that you can batch commits.

Also, one can prepare the git-svn clone once (and possibly while being
colocated with the server), and use it as a template instead of doing
additional full 'git svn clone's.

In the 450 seconds there were a few occurrences of a trunk directory
appearing and vanishing within tags, but otherwise the roundtrip time
was the limiting factor, not the bandwidth.

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Need for a local Subversion server?

[Andreas Krey <a....@gmx.de>]

On Sat, 23 Jul 2011 11:52:12 +0000, Stefan Sperling wrote:
...
> 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!). ..............  But manually
> computed mergeinfo can still be wrong even if it is syntactically correct.

And are very likely to get wrong. May it be possible to first do
the merge via git-svn, and then fix the mergeinfo with 'svn merge
(--reintegrate) --record-only'?  One would need to 'git svn fetch' and
clean up afterwards, but have the advantages of git's merge algorithms.

...
> If your use of git-svn does not involve merging between Subversion
> branches it is probably safe.

I usually use git-svn for 'regular' in-branch work, and fall back to svn
for merges (the few I need to do).

Also git-svn comes in quite handy, along with gitk, to visualize branches
and merges in svn, and to simply see from where tags have been made
(trunk or some branch).

Is there some visualization that can do the same for svn natively,
for a whole tree (as opposed to single files).

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: Need for a local Subversion server?

[Stefan Sperling <st...@elego.de>]

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.

Re: Need for a local Subversion server?

[Les Mikesell <le...@gmail.com>]

On 7/22/2011 12:12 PM, Phil Montgomery wrote:
> I have a question regarding the need of a subversion mirror server.
>
> Our work is done on UNIX systems.  We currently have a master repository
> in England.  We mirror it as a read only repository to the states.  The
> system that acts as the Subversion server in the states is rather old
> and its faster to do checkouts from the remote repository then the local
> one.  I’m curious why we even need a local subversion server.  We cannot
> add anything to the local repository.  Developers check out the code,
> update the files in their working directory, then commit them to the
> remote server.
>
> Now trying to commit, resolve conflicts, and merges are another matter.
> Latency has a far greater impact on those tasks.  We often thought about
> making a post-hook on the commit to initiate syncs from the master to
> the remote site in order to do the conflict resolution locally, allowing
> our developers to use a GUI interface or type in their xterm and not
> wait for the characters to appear.  We have yet to do that test to see
> if it would help.

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.

-- 
   Les Mikesell
    lesmikesell@gmail.com