Stefan Sperling wrote:
> On Mon, May 12, 2008 at 03:18:34PM +0100, Tom Widmer wrote:
>> Ilyes Gouta wrote:
>>> Hi!
>>>
>>> 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
> repository
>
> or
>
> - one repository with multiple branches, a so-called vendor branch
> for the upstream code, and the trunk that people merge into from
> their branches
My understanding is that the vendor branch is a branch of the whole repo
trunk in the OP's case. I may have misunderstood of course.
> None, I would say. So why does he really need a distributed VCS?
Well, strictly speaking, he doesn't need to use version control at all,
but for convenience, a DVCS is going to be much simpler. SVN vendor
branch handling allows you periodically to drop new versions into a
vendor branch, using a script (perl?) that attempts to create a
reasonable diff between versions to make merging the upstream changes
with any local changes you've made a bit simpler than having to redo all
the local changes manually. The fact that the source of these versions
is another Subversion repo doesn't provide you with any extra automation
of this process vs. just using periodic tarballs generated from that
repo, and the process is error prone in that renames, etc. in the
original repo aren't tracked when you update the vendor branch (at least
not without a lot of manual fixing up). Another way to handle
integrating changes would be manually to create a patch from the latest
changes in the upstream repo and apply that to the vendor branch in the
team repo (but since Subversion doesn't have a patch applier built in,
you'd need to use something else for that. A DVCS? ;).
Contrast:
//switch to 'main branch' if necessary. Then:
<dvcs>-svn pull|fetch|whatever
//and possibly:
<dvcs> merge|update
//each developer gets latest from team repo to their local repo:
<dvcs> pull|fetch|whatever
with the Subversion alternative, which requires running the vendor
branch script, manually fixing up any renames, etc. committing the
changes, then merging the changes into trunk in the team repo and
dealing with the conflicts, then each developer merging the changes into
their branches (if necessary).
You could write a script to help with this, of course.
> A nice fact to note in this context is that the Mercurial
> book recommends cloning a repository to do branching.
In both Git and Mercurial you can have in-repo branches as well as
whole-repo clones (in Git you often do just have a single repo with lots
of branches, though I agree this isn't the norm in Mercurial).
> 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.
Fine for branches in the local repo, but that doesn't help with
integrating changes in the vendor "branch" (a.k.a. the upstream repo).
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.
Not really, no. In this case, distributed is a much better fit IMHO. If
he only needs to integrate changes in the vendor branch very
occasionally and doesn't need to push them upstream, it might be
bearable, but it's going to be a nightmare otherwise (because Subversion
doesn't provide any help with keeping two separately developed repos in
sync).
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-05-12 19:07:21 CEST