Best practice for working with external vendor repositories?

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].