On Wed, Feb 17, 2010 at 11:08, Mark <markw_at_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
Received on 2010-02-17 13:47:06 CET