[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Need for a local Subversion server?

From: Les Mikesell <lesmikesell_at_gmail.com>
Date: Fri, 22 Jul 2011 13:01:06 -0500

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
Received on 2011-07-22 20:01:43 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.