ANN: pbranch extension (alternative to mq, like topgit and bzr loom)

[Peter Arrenbrecht]

On Fri, Dec 12, 2008 at 5:13 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
>
> Hi,
>
>> I have developed a branch-based alternative to MQ which I think is
>> very useful for collaborative development and/or long-term maintenance
>> of patches. Check out the extensive tutorial at:
>
> Simply reading the tutorial and without actually trying it out:
>
> - manually editing .hg/patchgraph sounds unwarranted for the simple cases.
> Could there be a command "hg pinit patch-C" which does something like:
>    "echo 'patch-C: <name of current branch>' >> .hg/patchgraph"
>  followed by:
>    "hg branch patch-C"
> (or the reverse)?

This is in the pipeline:

  http://www.bitbucket.org/parren/hg-pbranch/issue/14/add-pnew-command

> - the backport examples don't look convincing because they are much too
> simplistic. I don't understand how "hg reapply" could help in a real-world
> scenario with non-trivial patches.

Well, I have used this very approach with good success. Better in any
case than when trying to backport stuff using MQ. There, I more than
once lost work (deleting patches too early, not qrefreshing properly,
etc.). But your mileage may vary. Anyway, it's just one way to get
your work backported.

The key thing for me is I can commit the work right away first, thus
saveguarding it, and only then bother about backporting in a
non-destructive way.

But if you have better suggestions, they are certainly welcome.

> - in "Deleting a patch", you say "We back out all the changes introduced by
> patch-B". Shouldn't that read "We back out all the changes introduced by
> patch-B1"?

Thanks for catching this. Fixed here.

> - why isn't .hg/patchgraph committed in the repo? I see ".hg/patchgraph is a
> file designed for editing by hand, comments and all". But it seems that in most
> simple cases, people don't need to do hand editing if they are provided with a
> few basic commands (e.g. "hg pinit" above).

Ah, that's a longer story. At first, I didn't have any patchgraph file
at all. The graph was managed purely in .hg/the-patch.dep files, each
taken from the tip of its branch. This was workable, but required a
plethora of graph-changing commands. And I felt it did not allow one
to conveniently rearrange a graph except with baby-steps. Too, I
actually quite often edit the .hg/patches/series file by hand and very
much like the fact that I can. Especially for placing guards.

Second, where do you commit the file? On which branch, that is? I did
experiment with using a special, dedicated, out-of-band branch for
this (also called .hgpatchinfo). And I am considering bringing it back
so the patchgraph file can be shared. But it would be an optional
thing. See here for details on the idea:

  http://arrenbrecht.ch/mercurial/pbranch/blog.htm#pagetoc__1_1

While seemingly elegant in that it did not introduce .hgpatchinfo/*
files into the real branches, this approach did not work out fully
because it lacked a way to go back in time consistently (meaning you
can update back to an earlier rev and get exactly the pdiffs back you
had then, across clones).

>
> - In "Merge Resolving Conflict", the output of "hg up p1" says "use hg pmerge"
> but in the following command you use "hg merge" instead. This doesn't look
> intuitive.

Yes, I've noticed, too. And I'm going to change the example to verify
that using pmerge in this situation will actually do the right thing
(attempt the merge, then bail because it has an unresolved conflict
other than in the .dep file). Issue:

  http://www.bitbucket.org/parren/hg-pbranch/issue/17/use-pmerge-in-merge-of-p1-in-collab

Antoine, thanks a lot for your detailed feedback!
-parren