Using Mercurial rebase extension to manage trac patches with mq when upgrading

[Keshav Kini]

Hello,

The sage-devel message archive doesn't seem to contain anything about
this, so I thought I'd share this with you all, just in case it's not
common knowledge among more seasoned developers than myself...

It is possible to use the "rebase" Mercurial extension to more easily
rebase mq patches when upgrading your Sage installation. Generic
instructions for Mercurial users can be found in this nice screencast
by Steve Losh: http://hgtip.com/tips/advanced/2010-02-11-merging-mq-patches-with-rebase/
Unfortunately the instructions given don't exactly mesh that well with
the Sage upgrade process, since `sage -upgrade` doesn't just pull into
the sage installation's various Mercurial repositories - it seems to
also attempt to merge split heads. However, this can be dealt with by
doing everything "after the fact", as I will explain below.

In order to follow these steps you should use Mercurial 1.3 or newer
(Sage's current version of hg is much newer than this, by the way),
and you should enable the rebase extension by adding "rebase = " to
the [ui] section of ~/.hgrc (or wherever your hgrc is).

1) `hg qrefresh` or `hg qnew` to save uncommitted changes into the top
patch on your queue, or a new patch on the top of the queue, as you
prefer;
2) `hg qpop -a` to get all the mq stuff off the main repository's
history and make the working directory a clean copy of your old
version of Sage;
3) `sage -upgrade http://path.to.sage.files/` to do the upgrade;
4) `hg update -C -r old.version.number` (where old.version.number is
the old Sage version number) to get the working directory back into a
state your patch queue will work on;
5) `hg qpush -a` to put your patches back onto the pristine old
version;
6) `hg heads` to check for the revision number of the "true" head of
the repository (the one just upgraded to, i.e. the head which is not
your top mq patch, the head you want to rebase your patches to)
7) `hg rebase -d other.head.rev.number` (where other.head.rev.number
is the number you just looked up in step 6) to update the patches so
that they apply to the new Sage version instead of the old one.

The reason that in step 4 we could use the version number but in step
7 we had to check the revision number is that in the official sage
releases, the version number is not tagged to the actual head of the
repository, but to a revision one or two entries down the history
graph. This is, I guess, because the tags file itself is also tracked,
so you can't tag the latest revision without creating another revision
to record the fact that you tagged it. In my experience not much
changes between those two or three changesets so applying your mq
patches to the "wrong" revision in step 4 is not going to cause any
problem, unless your mq patch is messing with the tags file.

It will sometimes happen that the rebase extension can't figure out
how to merge your patches, so then it should launch whatever 3-way
merge tool you have configured for mercurial to use (such as kdiff3 or
vimdiff), allowing you to supervise the merge process. If you quit the
merge without resolving the conflict, you can then either use `hg
rebase --abort` to revert the repository to how it looked after step
5) above, or use `hg rebase --continue` to relaunch the merge tool.

After this process has been completed, you're done, and all your mq
patches have been rebased to the current version of sage. If you want
to copy these new patches somewhere, of course, they are sitting in $
(hg root)/.hg/patches/ .

Hopefully this is useful to someone - at least there were a couple of
people in the IRC channel who didn't seem to know about this procedure
when I mentioned it there some weeks ago... Maybe it should also be
mentioned at http://www.sagemath.org/doc/developer/walk_through.html#upgrading-sage-with-queues-present
.

-Keshav

[Rob Beezer]

Very nice!

On Feb 11, 3:54 am, Keshav Kini <keshav.k...@gmail.com> wrote:
> Hopefully this is useful to someone - at least there were a couple of
> people in the IRC channel who didn't seem to know about this procedure
> when I mentioned it there some weeks ago... Maybe it should also be

> mentioned athttp://www.sagemath.org/doc/developer/walk_through.html#upgrading-sag...

Yes, please do.

Rob

[David Roe]

It will sometimes happen that the rebase extension can't figure out
how to merge your patches, so then it should launch whatever 3-way
merge tool you have configured for mercurial to use (such as kdiff3 or
vimdiff), allowing you to supervise the merge process. If you quit the
merge without resolving the conflict, you can then either use `hg
rebase --abort` to revert the repository to how it looked after step
5) above, or use `hg rebase --continue` to relaunch the merge tool.

Thanks for the tip.  Does anyone know a good 3-way merge program that works on OS X?
David

[Jason Grout]

I've used kdiff3. It's not pretty compared to some other osx apps, but
it works well.

Thanks,

Jason

[Keshav Kini]

On Feb 12, 12:07 am, Rob Beezer <goo...@beezer.cotse.net> wrote:
> > when I mentioned it there some weeks ago... Maybe it should also be
> > mentioned athttp://www.sagemath.org/doc/developer/walk_through.html#upgrading-sag...
>
> Yes, please do.
>
> Rob

OK, I've added a trac ticket: http://trac.sagemath.org/sage_trac/ticket/10782
If someone could review it that would be great.

By the way, typo in the OP - to enable the rebase extension, you need
to edit the [extensions] section of your .hgrc file, not the [ui]
section. Sorry about that.

-Keshav