Charles Bouillaguet <charles.bouillag...@gmail.com> writes: > Hi all, > > I just tried to upgrade from 5.4 to 5.4.1, and it worked. > > However, the upgrade process interacts bizarrely with mercurial's > patch queue. I had a non-empty patch queue, and applied the upgrade. > But now, all the upgraded files appear as "uncommitted local changes", > and I can't really use the queue anymore. I can potentially break a > lot of stuff by doing "hg revert --all". > > It would probably be safer to check if there are local change to the sage > library repos before applying the upgrade, and the upgrade process should > complain if it is the caseā¦
I agree - you shouldn't upgrade with a patch queue in place. IMHO upgrading Sage should blow away any code changes you've hacked into your copy of Sage (with an appropriate warning beforehand, of course), and once you've upgraded, you should have a clean copy of Sage. I think that's typically what people would expect from the installer of any other piece of software, or from a package manager's "upgrade" command. What the upgrade process actually tries to do, though, is *merge* your local changes with the new version you're upgrading to. You can see in the installers for the main Sage SPKGs that `hg merge` is literally called during the installation process... But as far as I can tell, the code for these upgrade semantics was written before the Sage developer community collectively discovered queues, back when people were still using `hg commit` and `sage -clone`, which nobody uses anymore (at least according to a straw poll on sage-devel some months ago, as I recall). So the current behavior seems to be to just break / "interact bizarrely", as you put it, which is obviously not ideal. See also http://trac.sagemath.org/sage_trac/ticket/10988 . I made it not with an eye to preventing this behavior with patch queues, but rather to make it possible to upgrade from one development version to another without the weird merge errors the current upgrading semantics produce. I never actually got around to doing anything about it in the end, partially because this problem ought to go away once we do the planned workflow revamp / switch to git. -Keshav -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.