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 <<a href="http://jameswestby.net/tips/tips/hacking-a-project-with-bzr.html">http://jameswestby.net/tips/tips/hacking-a-project-with-bzr.html</a>> 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