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
