A new users thoughts on mercurial queues

[Matt Rosencrantz]

OK, pbranch does look much closer to what I want, thanks!  There are
so many overlapping features in this area, it's tricky to hone in on
the right one so I really appreciate you both taking the time to
reply.

I think as a new user I've followed this chain of features looking for
the one that fit:
clone->attic->branch->lbranch->mq->pbranch

When I started the search I was interested mainly in two things:
1 - the EWD problem, pushing nice focused patches upstream
2 - getting used to the fact that many mercurial commands don't like you
     to have uncommitted changes in your working directory (which tends
     to encourage the creation of revisions that are incomplete)

I think the critical leap from lbranch to mq was realizing that I
really didn't want the revisions in my local repository to map to
revisions in the upstream repo.  I need to be able to commit
unfinished things locally, but then somehow push something coherent.
So if I was explaining patch branches to a new user I would frame it
as a very organized way to group local revisions into what will
eventually become bigger, more coherent upstream revisions.

My plan now is to use pbranch and when a patch is finally ready
pexport|import it to a pristine clone that I have just for pushing,
and push from there.  Then if that patch was at the head of it's
branch I can close the branch and then pull in my main local repo and
pmerge the new change into the other patches.

Does that seem like a reasonable workflow?  I hacked up a quick python
script to automate the push of patches upstream, so far it seems to
work great.  However, if there is some other critical piece I should
know about I'd love to hear it.

Thanks for your advice,
Matt

On Mon, Apr 19, 2010 at 11:39 PM, Peter Arrenbrecht
<peter.arrenbrecht at gmail.com> wrote:
> On Tue, Apr 20, 2010 at 7:28 AM, Bill Barry <after.fallout at gmail.com> wrote:
>> Matt Rosencrantz wrote:
>> > In all of this I'm mainly interested in using queues to solve
>> > entangled working directory problems and building up my own patches
>> > while frequently re-basing against some shared repository somewhere.
>> > I know there are other cases I haven't thought about.
>>
>> This is one of the major use-cases of mq, but perhaps you would be better
>> suited to pbranch. Admittedly it is a bit more confusing up front (I think
>> the examples could use a bit more work) but as soon as you start groking it,
>> it suddenly all just makes sense and you wonder why you were screwing around
>> with a versioned mq repo so hard.
>
> Maybe it helps if you don't think of pbranch as a tool to manage
> patches per se, but as a tool to manage the flow of merges between
> related feature branches.
> -parren
>