[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Best practice for working with external vendor repositories?

From: Jamie Thompson <me_at_jamie-thompson.co.uk>
Date: Mon, 16 Feb 2009 23:52:33 +0000

Mark Eichin wrote:
> The traditional approach is to have a "vendor branch"; you'd use
> svn-load.py to pull upstream code into a branch, copy that branch to
> your trunk, do your work on trunk, re-pull to the branch, merge from
> the branch to trunk over time. Externals don't really help here
> (well, you could modify svn-load to use one as the upstream source, I
> suppose?) since what you're doing is marking "last pull" and "this
> pull", and using that to produce a diff that you apply to your trunk
> (and do your conflict handling there.)
> (By "traditional" I mean "this is why CVS was written in the first place" :-)

Ah. That's a pain. "Vendor branch" seems to be the magic words I need to
keep an eye out for.

I had a play with some test repos and confirmed my way just isn't
supported. A real shame IMHO, as it seems logical enough. It'd be great if
externals were expanded or an equivalent super-external were supported.

Don't suppose you know if svn load dirs imports everything so my copy is
exactly the same as the vendor branch? i.e. full history, etc? That's the
main thing I don't want to lose, as having single big 'ol merges from time
to time doesn't really help when looking at incremental diffs.

- Jamie


To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].

Received on 2009-02-17 01:10:48 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.