Managing independent patches

[Paul Moore]

I'm thinking about using Mercurial to manage a series of patches to a
project (wspecifically, the Python core). In principle, Mercurial
Queues are exactly what I need, but there are a few issues that worry
me. I wonder if anyone could help.

The big question I have is that my patches are essentially independent
- I would want each patch to apply cleanly against the upstream
version, not against the previous patch. MQ seems more geared towards
handling a dependent series of patches. In practice, this is not
likely to be an issue all of the time, as I expect patches to
generally work on separate flies.

The things I see as being necessary are:

1.  I would want my patches versioned, as they could potentially live
for quite a while and need changes made as time goes on. If I need to
revert a patch, it will only be one patch I revert. So I'd always be
doing reversions on the patch repository on a per-file basis, which
seems error-prone. It would only take one revert where I forgot to
include the patch name to revert more than I intended.

2. I think I'd spend a lot of time editing the series file to switch
the order of patches so that my "current" patch is the first one (and
hence, the only one I have applied).

3. Each time I pull from upstream, I've got a lot of work to do to
rebase every patch.

The two alternative approaches which come to mind are (a) to simply
have a set of repositories, one for each patch, or (b) to use a series
of feature branches in a single repository.

The problem with multiple repositories (which is effectively the same
workflow as I have with subversion) is that I need to build the
project in each repository, and keep those builds up todate as I pull
from upstream. This is wasteful, as in practice many of my patches
will be to documentation, tests or Python code, and so won't affect
the interpreter. With a single repository, I could just build once and
not need to rebuild unless I pull from upstream (and when I do pull, I
only need one rebuild).

The problem with feature branches is mainly that I haven't got a clue
how I'd pull from upstream and then rebase multiple (say 10 just for
definiteness) feature branches.

As I said, I think MQ is the correct approach. And maybe I simply
shouldn't worry too much about the patch dependency issue. But could
someone give me some hints? I suspect this is a common situation, but
I couldn't find it covered in the wiki or the manuals (which may say
more about my searching ability than the quality of the docs!)

If it is undocumented, I'll put what I find out up on the wiki.

Thanks,
Paul.