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

Re: Distributed Subversion Repositories

From: Julian Phillips <julian_at_quantumfyre.co.uk>
Date: Wed, 17 Feb 2010 11:18:18 +0000

On Wed, 17 Feb 2010 12:09:02 +0100, Stefan Sperling <stsp_at_elego.de> wrote:
> On Wed, Feb 17, 2010 at 10:08:12AM +0000, Mark wrote:
>> I have the following problem. Repository A is used by a lab of
>> developers. 1 developer needs to work off site against the code base
>> held in A, for an extended period of time. He requires version
>> control, but cannot gain access to Repository A. To solve this we
>> can dump/mirror A into repository B. During this period A and B will
>> independently updated. When the off site developer returns we need
>> to combine B back into A. Any advice on whether this is possible
>> under Subversion, should we be dumping, how to combine, pitfalls
>> and options/hints much appreciated.
> Subversion itself does not support this use case.
> So it's not the right tool for the job. (I'm a Subversion developer
> so I'm allowed to say this with some level of authority :)
> There was an add-on tool called 'SVK' which made this use case
> possible, but it is no longer being maintained. Mostly because
> better alternatives exist nowadays.
> I would recommend to use Mercurial to version changes while off-site.
> Its command set is very similar to Subversion, so it's not hard to
> adjust coming from svn, and even to switch back and forth on the fly.
> You can easily overlay a subversion working copy with a Mercurial
> repository:

If using a different tool is an option, then there are tools that let you
interact directly with Subversion repositories from various other SCM
tools, e.g.


Then you don't have to worry about manually commiting back to Subversion

Received on 2010-02-17 12:18:55 CET

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.