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:
$ ls -a
./ ../ .svn/ alpha beta epsilon/ gamma/
$ echo .svn > .hgignore
$ hg init
$ hg add .hgignore
$ hg add
adding alpha
adding beta
adding epsilon/zeta
adding gamma/delta
$
Then just work with Mercurial as usual (see http://mercurial.selenic.com/)
However, deleting, moving, and copying operations are a bit annoying.
You'll have to make sure to tell the svn working copy about any tree
changes you are making. But I guess off-site development won't usually
involve refactoring, so this limitation may be irrelevant.
Another downside is that the Subversion working copy will see all changes
committed to Mercurial in accumulated form, as one giant change.
But Mercurial has an answer to that, too. It is called Mercurial patch queues:
http://hgbook.red-bean.com/read/managing-change-with-mercurial-queues.html
With patch queues, you can manage changes which are based upon one another
as a series of patch files (which, in turn, can also be versioned).
Later you can commit the patches to any version control system (be it CVS,
Subversion, or even Mercurial itself). I use hg patch queues whenever
I'm forced to work with CVS or Subversion repositories I don't have commit
access to, or cannot (or don't want to) expose my changes to the repository
yet. It works quite well. But, again, it cannot handle tree changes in a
way Subversion will understand.
We're planning on adding some sort of patch queuing or offline commit feature
to Subversion eventually, but not in the near feature (certainly not within
the next year). Once it exists, it will also handle tree changes.
Stefan
Received on 2010-02-17 12:09:45 CET