mq: addressing the broken version history (qpush/qpop/qpush cycle)

Samuel Masham samuel.masham at gmail.com
Thu Dec 8 09:39:22 UTC 2005


Hi Chris, All,

I have been doing some playing as instructed and have managed to
address the issues with people using the mq maintained repository as a
source.

Obviously the degree of success in this case is somewhat subject to
interpretation but I feel its getting there... Also I am getting
somewhat busy so want to get this out there before i get swamped &
xmass hits

The bad news
- incompatible with the old mq, *don't* use with currently applied patch queue.
- breaks qpush -m -n xxxxx
- qrestore is untested (so qsave might not be doing the right thing ...)
- insufficient testing
- lots of changes ie:
  mq.py |  556 ++++++++++++++++++++++++++++++++++++++++++++++++------------------
 1 files changed, 407 insertions(+), 149 deletions(-)

(we could really do with a test suite for mq at this point... )

Now suitably warned I hope, on to what I tried to do.

The format of the series file has changed as follows:

revlog.hex(top):revlog.hex(top):.hg.pushtop.marker
revlog.hex(top):revlog.hex(p2):example.patch
....

So the parents of example.patch are .hg.pushtop.marker's
revlog.hex(top) and revlog.hex(p2)

The p2 information is not cleared over push / pop

The merge update uses this info, so to update all patches to a new baseline

hg qpush -a
hg pull
hg update -C tip
hg qpush -m -a

or if you update and decided that you don't want to merge

hg qpush -a
hg pull
hg update -C tip
hg qpush -f -a

this will throw away the old parent info, but as yet not strip out
matching versions from the repos. If you know you want to do this in
advance then the original version:

hg qop -a
hg pull
hg update -C tip
hg qpush -a

... is neater of cause.

As for working on clones from a mq maintained hg repos, the qtag
command will *save* changes from being striped out. This allong with
the qpush qpop keeping parent info means that the experience should be
less strange.

Ok I will leave it at that for now. Please ask about all the unclear bits...

Samuel

ps I have included two test scripts that should show the new merge
sequence and the rebase  sequence. Also I my diff includes the
auto-sync changes this time... i can split them out again if
needed....
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rebasetest.sh
Type: application/x-sh
Size: 757 bytes
Desc: not available
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20051208/fb5813f8/attachment-0002.sh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: workfrommq.sh
Type: application/x-sh
Size: 849 bytes
Desc: not available
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20051208/fb5813f8/attachment-0003.sh>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mq-39-sm.patch
Type: application/octet-stream
Size: 36897 bytes
Desc: not available
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20051208/fb5813f8/attachment-0001.obj>


More information about the Mercurial mailing list