You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Mark <ma...@hmgcc.gsi.gov.uk> on 2010/02/17 10:08:12 UTC
Distributed Subversion Repositories
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.
Thanks
Mark
The information contained in this message (and any attachments) may
be confidential and is intended for the sole use of the named addressee.
Access, copying, alteration or re-use of the e-mail by anyone other
than the intended recipient is unauthorised. If you are not the intended
recipient please advise the sender immediately by returning the e-mail
and deleting it from your system.
This information may be exempt from disclosure under Freedom Of Information
Act 2000 and may be subject to exemption under other UK information
legislation. Refer disclosure requests to the Information Officer.
The original of this email was scanned for viruses by the Government Secure Intranet virus scanning service supplied by Cable&Wireless in partnership with MessageLabs. (CCTM Certificate Number 2009/09/0052.) On leaving the GSi this email was certified virus free.
Communications via the GSi may be automatically logged, monitored and/or recorded for legal purposes.
Re: Distributed Subversion Repositories
Posted by B Smith-Mannschott <bs...@gmail.com>.
On Thu, Feb 18, 2010 at 03:59, Vincent Lefevre <vi...@vinc17.net> wrote:
> On 2010-02-17 11:18:18 +0000, Julian Phillips wrote:
>> 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.
>>
>> http://mercurial.selenic.com/wiki/WorkingWithSubversion
>> http://flavio.castelli.name/howto_use_git_with_svn
>>
>> Then you don't have to worry about manually commiting back to Subversion
>> ...
>
> But do they support properties?
git-svn doesn't fully support properties. I mean you can proplist and
propget, but not propset. git-svn itself ignores the various svn:*
when checking out, except for svn:executable. So no eol-style,
needs-lock, externals, etc.
When I've needed control over properties, I've just used svn directly.
git-svn works well for me in the way I use it, but really I'm using it
as a glorified patch-queue-manager.
// Ben
Re: Distributed Subversion Repositories
Posted by Vincent Lefevre <vi...@vinc17.net>.
On 2010-02-17 11:18:18 +0000, Julian Phillips wrote:
> 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.
>
> http://mercurial.selenic.com/wiki/WorkingWithSubversion
> http://flavio.castelli.name/howto_use_git_with_svn
>
> Then you don't have to worry about manually commiting back to Subversion
> ...
But do they support properties?
--
Vincent Lefèvre <vi...@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)
Re: Distributed Subversion Repositories
Posted by Vincent Lefevre <vi...@vinc17.net>.
On 2010-02-17 11:18:18 +0000, Julian Phillips wrote:
> 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.
>
> http://mercurial.selenic.com/wiki/WorkingWithSubversion
> http://flavio.castelli.name/howto_use_git_with_svn
>
> Then you don't have to worry about manually commiting back to Subversion
> ...
But do they support properties?
--
Vincent Lefèvre <vi...@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)
Re: Distributed Subversion Repositories
Posted by Julian Phillips <ju...@quantumfyre.co.uk>.
On Wed, 17 Feb 2010 12:09:02 +0100, Stefan Sperling <st...@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.
http://mercurial.selenic.com/wiki/WorkingWithSubversion
http://flavio.castelli.name/howto_use_git_with_svn
Then you don't have to worry about manually commiting back to Subversion
...
--
Julian
Re: Distributed Subversion Repositories
Posted by Stefan Sperling <st...@elego.de>.
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
Re: Distributed Subversion Repositories
Posted by B Smith-Mannschott <bs...@gmail.com>.
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