Downstream Patch Management [not PQM]

[Fergus Ross Ferrier]

Hello,

I'm getting slightly dizzy thinking about interoperability of the three big
distributed VCSs [Git, Bazaar, Mercurial] for open source packages that
interrelate. I use Bazaar for my own stuff at the moment.

I've just spent a couple of hours getting to know Mercurial just now, as I'm
using an upstream package that uses it for version control. This got me
thinking, and here's a situation I'd dearly love your thoughts on as I'd
like to keep in Bazaar as much as possible:

*Assumptions*
- I use several upstream packages in my project [let's assume they variously
do and don't use Bazaar]
- I would like to pull updates to this upstream code on an occasional basis
- I need to make a non-trivial number of modifications to those packages for
my project
- These modifications would be distributed as part of the project
- I would like to contribute my modifications to the upstream package [being
open source], but there is no guarantee that they will be used

*A Bazaar Solution*
I've read this article <
http://jameswestby.net/tips/tips/hacking-a-project-with-bzr.html> and that's
how I would envision it would best be done in Bazaar:

Upstream: one branch for current upstream code.
Patches: a branch per 'patch', which inherits from upstream branch.
Final code: one branch for the final code to use in the project, which
inherits from upstream branch and all the patches - theoretically this
branch would be published.

1. Branches are cheap, but spending time issuing lots of pulls from a
non-trivial batch of patches [needed each time you update the upstream code]
is not.
?Solution: put all patch branches into a folder and bzr pull them all at
once [via a shell script or otherwise per-directory  command].

2. Being asked to revise your patch by the upstream controller is a matter
of simply working on the relevant branch. On acceptance of a patch by the
upstream, you would simply update the upstream code and remove the branch
that hitherto resolved the problem. You would then be left with the final
code branch fixing the problem twice.
?Solution: reverse cherrypick [as it's a published branch] the final code
branch.

3. Patches not accepted by upstream provider = stale branches hanging around
?Solution: merge such rejects into one branch for local changes. This would
make things difficult if the upstream was patched later on - a reverse
cherrypick again.

Am I thinking about this wrongly? Is there something I've missed? Are
reverse cherrypicks as tortuous as I make out?

Many thanks,

Fergus Ross Ferrier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/bazaar/attachments/20090310/34b1400d/attachment.htm