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.


Reply via email to