On Wed, Feb 17, 2010 at 11:08, Mark <ma...@hmgcc.gsi.gov.uk> 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.
I use git-svn to work in this fashion, even when I'm in the office. (It allows me to clean up my local commits before really publishing them to the central repository.) I've been happy with this solution, though it does come with the downside of needing to understand two version control systems (git and svn) in order to use this competently. In my case, that proved profitable because what I've learned about version control from broadening my horizons to include git has made me a more competent svn user as well. More recently, I've been experimenting with bzr's built-in support for making local branches from svn repositories. I haven't really banged on it very hard, so I'm unsure about how robust it is, but it looks pretty nice. I've read that mercurial (hg) also has some kind of svn bridging analogous to git-svn. All three of these approaches would give your developer the ability to make commits locally (into bzr, git or hg) and then replay those commits into the central (svn) repository when your developer is on site again. (This is different and more powerful than just using one of these tools to put an svn working copy under local version control.) For the record, I was a heavy user of svk before discovering git-svn, but I was never really very happy with svk. I found it slow, poorly documented and prone to fail in confusing ways. // Ben