pbranches style plugin
adrian.wilkins at gmail.com
Mon Jun 1 15:12:21 BST 2009
So, I looked at bzr-loom.
My initial frustration with loom is that it only helps you if you are
managing one stack of patches. Each thread in the loom by necessity
depends on the threads beneath it. To me, this doesn't make it any
easier to maintain patches - I want to be able to take a known revision,
and branch it, and maintain a set - not a stack - of patches on top of
it. If I write a patch that's dependent on one or more of the others,
fine. But most of them are not.
Example (real world) :
I am maintaining a project which is hosted across multiple SVN
repositories. The project owner also has his own particular environment
in which he has access to a Maven repository that I do not. I want to be
* Branch the repository branches (which I've done, using bzr-svn)
* Patch the Maven pom.xml files so they use versions of the projects
for which I have the source, because I can build those, rather than
older versions, which are in the private repository.
* Fix bugs
* Make changes
Of these, I'd like to be able to push my bug fixes back to the
subversion repository, but I don't want to push my changes to pom.xml files.
My style of working is heavily informed by the Old Ways, and thus making
feature branches is not second-nature to me yet, but even if it was,
this would be lots of work.
I had a look at the beta Mercurial pbranches , and this seemed more
like what I needed than loom.
What would be really nice is a UI that will let you choose, down to a
per-hunk basis if possible, which bits of your commit go in which patch
branch, and do branch management. You continue to work in your work
branch, which is a merge of all the various threads beneath it. When you
commit, you mark each file or hunk to determine where it goes (and maybe
provide a comment for each target branch).
A pretty GUI for all this in qbzr would be doubly nice.
bzr-loom already introduces a way of managing multiple branches per
folder (by keeping track of their heads and using nicks to differentiate
them), so that part doesn't seem hard. There seem to be two components
== The branch manager ==
Which handles the business of which heads you are tracking and their
relationship to each other.
== The commit manager ==
Which either for real or otherwise
* Make a manifest of which bits to commit where
* Shelves your commit
foreach parentBranch in branch.parents():
That's long enough for a shot across the bow. I'll let people shoot
holes in the idea now.
More information about the bazaar