hg equivalent to "bk collapse"?
Giorgos Keramidas
keramida at ceid.upatras.gr
Sun Mar 18 21:16:31 UTC 2007
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
More information about the Mercurial
mailing list