hg equivalent to "bk collapse"?

[Giorgos Keramidas]

On 2007-03-18 15:14, Ben Hood <0x6e6562 at gmail.com> wrote:
>Giorgos Keramidas wrote:
>> I'm using MQ to do something similar so far.
>>
>> For instance, when I'm working on two bugs, which should be resolved in
>> the same commit, I make a clone of the repository and start with:
>>
>>   cd ws/project
>>   hg clone trunk gker
>>   cd gker
>>   hg qinit -c
>>   hg qnew -fm '144361 summary of bug 144361' 144361
>>   hg qnew -fm '144342 summary of bug 144361' 144342
>>
>> This lets me work with the two patches as a 'pair', but I can also
>> push/pop them at will or even re-order them.
>>
>> At various times, when I have a 'stable' version of the patches which I
>> want to test, I use qcommit to save the patch state:
>>
>>   hg qcommit -m 'summary of patch state'
>>
>> When I'm satisfied that it all works, and I want to push the patches
>> upstream, I pop them off the tip of the 'gker' repository, and I use 'hg
>> import' to make them real changesets on top of the tip.
>>
>>   hg qpop -a
>>   hg import .hg/patches/144361 && hg qdelete 144361
>>   hg import .hg/patches/144342 && hg qdelete 144342
>>
>> Then I can either 'hg push' two changesets, or hg diff with the last
>> version of the trunk tip which I pulled and 'import' that diff.
>
> I'm not an exprienced MQ user so this suggestion makes me ask 2 questions:
>
> 1. If you were working on a patch to an upstream tree, wouldn't you be
> using qrefresh to save the current state of the patch during the time
> that you are doing all of your own hacking and debugging? I would have
> thought that the end result is one patch without many changelog
> entries.

Yes, I'm using qrefresh to save the patch state.  What I didn't
explicitly write above is that the .hg/patches/ directory is an Hg
repository of its own.  By using 'qrefresh' a patch file is left in a
modified, but uncommitted state in the .hg/patches repository.

The 'qcommit' command makes the .hg/patches repository of patch sets
clonable too, by committing any changes to the patch files as normal
changesets of the .hg/patches/ tree.. I regularly use this to move
patches around Solaris machines with different native instruction set
(i.e. sparc vs. i386).

> 2. Doesn't the hg import at the end imply that you yourself maintain
> the upstream tree? If so, then why wouldn't you just be using MQ for
> that tree as well? Is there an advantage to importing it into native
> mercurial? Or is it so that you can send to another upstream tree that
> may not be using MQ?

I am not sure I understand this question.  Why would I have to be the
maintainer of the upstream tree too?

The example seems probably contrived, because it is just a way of me
using MQ to keep a fine-grained log of the patch files, and also be able
to use Hg as my every-day SCM in a Subversion-based environment.

I am using a workspace hierarchy like this:

    [Subversion repo]
          |
          |
     workspace  . . . .  (conversion script)
                                 :
                                 :
                           Hg 'trunk' mirror
                                 |
                                 | [hg clone]
                                 |
                        +--------x--------+------   ...
                        |                 |
                        |                 |
                       bugfix           bugfix
                       repo #1          repo #2     ...
                        :                 :
                        :                 :
                      (MQ patches)      (MQ patches)

I don't want to use MQ on the 'Hg trunk mirror' repository, because it's
supposed to be an Hg mirror of the Subversion trunk.

It's fine to use MQ in 'bugfix repo #1' though, and go through several
iterations of incomplete, or even bogus versions of a bugfix patch.
When I'm done, I use hg import to make the MQ patch a 'real changeset',
so I can then use "hg export" to prepare a patch(1) style diff, which I
can commit to Subversion.

I don't control the upstream Subversion repository, and I can't convert
the Subversion trunk to Mercurial, so I am using MQ to:

  * Help me maintain a fine-grained changelog of each patch in the
    bugfix workspaces, by frequent use of 'hg qcommit'.

  * Help me maintain a sane state of the patches, as I let changesets
    "flow" downstream from Subversion to my bugfix workspaces.

If I'm way off, please forgive the extra verbosity.  I probably
misunderstood your question and replied with something irrelevant.

- Giorgos