Concatenating changesets

[blr at robertsr.us]

> 	It sounds like mq might be the right tool for you for one of two uses:

I tried MQ, and it looks great for what it's made for, but if I'm
working on 3 un-related defect fixes, I had a hard time figuring
out how to make mq not insist there was some implicit order to
the patches.  I don't know which one I'm going to finish (and
want to push) first, and I don't know how to make mq do that.

>> Is combining changesets a bad idea (amd I still thinking in CVS),
>> or are there other, faster ways to do this with hg?
>
>
> 	It's up to the user.  I think it's a bad idea, some people think it's
> a great idea.  You seem to be leaning more to the right side of that
> sentence.  I wouldn't say it's a CVSism.  I've always committed early
> and often regardless of my tools.

Now I've come back to believing that I am still struggling to
un-learn CVS.  I was thinking of strictly linear development.

What I'm playing with now is developers create as many named
branches in their local repository as they have current tasks.
When they finish a fix or feature, they merge into the default
branch.  As long as they always 'push -r default' their
unfiniished branches stay local.  If one dies, they 'hg strip'
it.  Then all their micro-commits do go to the master repository,
but they're nicely hidden by being in a branch.

Does that sound like a distributed (mercurial-ish) way to work?
Well, besides the pushing to a master repository.

This list is great. Thanks for putting up with me while I try to
change my evil ways.

Barry Roberts