On Mon, May 12, 2008 at 03:18:34PM +0100, Tom Widmer wrote:
> Ilyes Gouta wrote:
>> I have a special use-case that I would like to have your opinion on
>> and if it's doable or not using Subversion. So, here it is:
>> I'd like to "clone" a public SVN repository and make the new
>> repository accessible to my team. Each member of my team will have his
>> working copy checked-out from the "cloned" repository, which is
>> internal, and will check-in its code to it. I'd like also to
>> periodically synchronize that repository with the public one to
>> reflect the latest public changes. So, the "cloned" repository will
>> act as a repo. as seen by my team members and as a "working-copy"
>> from the public repository point of view.
>> Is this doable using SVN?
> Well, it sounds like you really need to use a Distributed VCS,
For this use case, what's the practical difference between having
- multiple clones of a repository holding upstream code,
with people merging from their repositories into a central
- one repository with multiple branches, a so-called vendor branch
for the upstream code, and the trunk that people merge into from
None, I would say. So why does he really need a distributed VCS?
A nice fact to note in this context is that the Mercurial
book recommends cloning a repository to do branching.
With Subversion, you copy your trunk into another directory
in the same repository instead. Same thing in practice from the
developer's point of view. It's just that these two systems
use different numbers of repositories to do the same thing.
"Distributed vs. centralised" is not an issue here at all.
The job that's being asked for can be done with either type
of version control system.
Received on 2008-05-12 16:36:51 CEST
- application/pgp-signature attachment: stored