Tom Widmer wrote:
> 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? ;).
You should check out piston. It handles a vendor branches very easily.
http://piston.rubyforge.org/
Blair
---------------------------------------------------------------------
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 21:08:45 CEST