Re: does vendor branch processing take advantage of repo history?

Robert P. J. Day wrote:
> i'm not sure i even know what i'm about to ask here but, what the
> heck, let's give it a shot. i'm wondering if there's a processing
> advantage to handling vendor branches when the vendor is also using
> subversion.
>
> consider the explanation of how to handle vendor branches here:
>
> http://lookfirst.com/2007/11/subversion-vendor-branches-howto.html
>
> clearly, in that example, the author wants to merge the difference
> between the vendor's versions 5.5.0 and 5.5.7. but because the vendor
> (apparently) isn't using subversion, the author downloads the pristine
> source code corresponding to those two versions, checks both into a
> subversion repo, and uses those as the basis for the vendor branch
> merge. so far, so good, and it should clearly work (barring have to
> deal with any conflicts).
>
> but since those checkins are from pristine source code (versions 5.5.0
> and 5.5.7), there will clearly not be any repository history showing how
> the vendor got from one to the other, and the subsequent merge can work
> only with a straight textual diff between those two checkins. am i
> making sense so far?
>
> however, imagine the vendor was using also subversion, and you had
> (read-only, of course) access to their source code repos. obviously,
> you can skip all that un-tarring and checking in on *your* end, and just
> merge directly against the two versions in your vendor's repository.

If your vendor is using Subversion and you have read access to it, you can use
Piston to do vendor management:

http://piston.rubyforge.org/

Regards,
Blair

-- 
Blair Zajac, Ph.D.
CTO, OrcaWare Technologies
<blair_at_orcaware.com>
Subversion training, consulting and support
http://www.orcaware.com/svn/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org