[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: Mark Eichin <eichin_at_gmail.com>
Date: Mon, 16 Feb 2009 00:26:04 -0500

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" :-)

On Sun, Feb 15, 2009 at 10:52 AM, Jamie Thompson
<subversion-users_at_jamie-thompson.co.uk> wrote:
> Hey,
> I've had a look through some of the archives, but I'm not entirely sure how to
> phrase what I want, so haven't had a great deal of luck in forming useful search
> terms :)
> Anyway, from time to time I feel the need to scratch an itch with an OSS
> project, so download the code and make my changes: all is well until upstream
> updates, then things become a pain. If the change is small, maintaining a patch
> is usually sufficient, but when you're adding more substantial changes, (i.e. a
> mini or full blown fork), then it makes more sense to work from a working copy
> of their SCM to ease merges with new content. In practice however, as I'm unable
> to commit to their read-only repo, I end up with an increasingly unwieldy
> working copy.
> I have just begun working on a project that uses Subversion (hurrah!), and I'd
> like to avoid this unpleasant future if I can, as I already know before I start
> this time that my changes will be quite significant.
> Distributed SCM systems solve this in their own ways, but with Subversion I'm
> not clear how to achieve this, as I've only ever used externals for pulling in
> read-only modules and content, never as a source branch that will be continually
> merged from.
> My mental image is of pulling in the upstream as an external, then branching off
> the local external, making my changes (and being able to commit), then taking
> advantage of the fairly recent merge tracking features to assist with the
> merging from the external as required, but I have a suspicion that that's not
> how externals and the merging features work but I'd love to be wrong...
> ...can anyone shed any light on this and suggest some working practices?
> -Jamie
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1165250
> To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].

_Mark_ <eichin_at_thok.org> <eichin_at_gmail.com>
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-16 06:27:01 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.