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>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1168741
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-16 06:27:01 CET