ann: attic extension (alpha quality), request for help

[Peter Arrenbrecht]

2009/1/15 Bill Barry <after.fallout at gmail.com>:
> Greg Ward wrote:
>
> On 13 January 2009, Bill Barry said:
>
>
> http://bitbucket.org/Bill_Barry/hgattic/changeset/74444dd0c72d/#chg-attic.py
>
>  From the doc header:
>
> This extension lets you work with a set of disjoint patches in a
> Mercurial repository. With it you can task switch between many patches
> in a single repository and easily share patch sets between
> repositories.
>
>
> Isn't that sorta-kinda what the "pbranch" extensions is supposed to
> do?  It was announced here:
>
>
> http://thread.gmane.org/gmane.comp.version-control.mercurial.general/10994/
>
> Disclaimer: I'm could be talking nonsense here; I haven't used pbranch
> at all, although it sounded interesting when I read that thread back
> in December.
>
>
> I suppose pbranch might be seen as a mostly a full superset of both mq and
> attic. As I am not using 1.1 yet (I'm a satisfied tortoisehg user), I
> wouldn't exactly know (I'd love to try it out, but I am not going to go
> through manually compiling tortoise at this time, and even still I only have
> the very inklings of understanding as to how all this python stuff works).

THg 0.6 is out which might help.

> This whole thing is designed with the goal of making it really easy to share
> individual patches for a codebase. For example:
>
> My coworkers and I have our clones in our local hard drives and we all share
> a set of central repositories that we push to and pull from. One of them is
> currently working on a bug and I am working on a new feature. At the end of
> the day neither of us is anywhere close to being where we want to be. So, on
> my machine I do:
> hg shelve -m "this is the message that will be on the commit when I am done
> with this patch" somenewfeature.patch
> cd .hg\attic
> hg addrem
> hg ci -m "stowing away partial work for the day on somenewfeature"
> hg push
>
> My coworker:
> hg shelve -m "fixes bug xxx by doing this here" bugxxx.patch
> cd .hg\attic
> hg pull
> (he knows I already pushed first)
> hg up
> hg addrem
> hg ci -m "partial fix for bugxxx, causes build to fail at the moment"
> hg push
>
> The next day I come in early and I have a brilliant idea of how to fix his
> bug:
> hg unshelve bugxxx.patch
> (hack)
> hg sfinish
> hg unshelve somenewfeature.patch
> (do some more)
>
> Then he comes in and we have our daily morning meeting where I let him know
> I have fixed his bug (he would see that anyways when he looked at his email,
> but ...). I tell him that I want his opinion on the feature I am working on
> and I do this:
> hg rebuild
> cd .hg\attic
> hg addrem
> hg ci -m "applied bugxxx.patch and continued work on somenewfeature"
> hg push
>
> he does:
> cd .hg\attic
> hg pull -u
> cd ..\..
> hg unshelve somenewfeature.patch
>
> meanwhile I get a phone call and have to go fix some critical bug somewhere:
> hg shelve
> (fix bug)
> hg ci -m "fixed bug xxx"
>
> and my coworker decides that he is going to continue working on
> somenewfeature. So I take the next thing on the list to do:
> (do some work)
> hg shelve somethingelse.patch
> hg unshelve
> (continue)
>
> This is all too often the actual process that happens here. We are switching
> tasks nearly as often as we are actually doing anything substantial. So, I
> created an extension that lets me actually do what I am already doing
> anyways (in a much more manual process of abusing mq).
>
> You will want to get the latest version if you do try this extension as I
> have fixed the sfinish command and I think the whole thing basically works
> now (it just needs tests and a bit better CLI so that it is easier to know
> what you are doing). It doesn't mess with your history and so shouldn't
> screw stuff up (at least I hope not, I don't believe I've called any
> possible history altering methods other than commit in sfinish).

pbranch was not primarily designed for this quick juggling of patches.
Rather, it was designed for longer lived, collaboratively developed
patches.

That said, I think pbranch could be used for the purpose, but with some warts:

The transition from patch to finished commit is more cumbersome with
pbranch at the moment. The reason being that a pbranch repo always
separate from the main repo. You never push from the pbranch repo to
main (by pushing only a given branch we might relax this).

Finished and deleted patches don't just go away. They linger on as
named Hg branches.

On the other hand, it handles complex patch DAGs with octopus merges
at the patch level (a patch depending on multiple other patches).

-parren (pbranch author)