pbranches style plugin

[Jonathan Lange]

On Tue, Jun 2, 2009 at 12:12 AM, Adrian Wilkins
<adrian.wilkins at gmail.com> wrote:
> 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.
>

Using feature branches *is* second nature to me and I sometimes find
the strict ordering of threads in a loom to grate. I've often got a
stack of patches, except that maybe three of the patches could land in
any order.

I do think that the ordering of threads is an asset to the user
interface, and think it would be a shame to see it replaced with
something more complex.

I wonder if there's a good way of handling your use-case without looms.

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

I agree that this sort of interactive commit would be nice. With loom
as it stands, I often find myself manually shelving, committing,
switching, unshelving etc.

I also thing that this would fit well within loom's existing design.

> A pretty GUI for all this in qbzr would be doubly nice.
>

+1

We showed loom to Gary at the UDS sprint and he's already started
thinking about how to get loom working well with qlog.

jml