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

Bill Barry after.fallout at gmail.com
Thu Jan 15 12:36:41 CST 2009


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). 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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://selenic.com/pipermail/mercurial/attachments/20090115/db0a7afc/attachment.htm 


More information about the Mercurial mailing list