pbranches style plugin

[Adrian Wilkins]

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 
able to

  * 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 [1], 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 
required

== 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

process(workBranchCommit.branch())

def process(branch):
   foreach parentBranch in branch.parents():
     process(parentBranch)
     branch.merge(parentBranch);

   if(commitManifest.hasHunksFor(branchCommit):
     switchToBranch()
     unshelveHunks()
     commitThem()


That's long enough for a shot across the bow. I'll let people shoot 
holes in the idea now.

[1] http://arrenbrecht.ch/mercurial/pbranch/