Concatenating changesets

[Gregory Collins]

blr at robertsr.us writes:

>> 	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.

Pop them all ("hg qpop -a") and reorder the .hg/patches/series file by
hand. If the patches commute (i.e. one doesn't depend on the other) this
should be seamless.

> 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.

I'd say most projects using hg have some kind of master repository. What
you've described is roughly my working process, except that I use
multiple cloned repos instead of named branches. As a longtime CVS user,
I found named branches conceptually more familiar, but the workflow is
clunkier (or *was*, at the time that I first picked up hg).

If you're using Mercurial as a "better CVS", that's perfectly fine, but
IMO the real advantages come when you start thinking about ways to tweak
your repository topology to fit your workflow. For example: does
everyone really *need* commit access to the central trunk?

G.