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 -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org