On Dec 7, 1:37 am, Robert Bradshaw <[EMAIL PROTECTED]>
wrote:
> On Dec 5, 2008, at 5:10 PM, William Stein wrote:
<SNIP>
> > You have to manually resolve this merge conflict by editing
> > integer.pyx, choosing one of the two options, and then
> > check in the result of doing the merge.
>
> I think upgrading should *fail* (right at the start) if a merge is
> required. Either that or it should move the sage-main directory out
> of the way rather than doing a merge 30 minutes into it. Thoughts?
Well, I would generally advocate that people who upgrade would do so
on a vanilla clone. Moving the sage-main directory out of the way
would not get us the benefit of the short upgrade time unless we had a
list of "good" revisions" we could clone off, but that seems error
prone and could lead to more failures than we currently see. In
general "-upgrade $URL" is for advanced users only and it does give a
warning at the start. If you are monkeying around in the sage repo you
should know what to do in case of a merge, but that is not always
easily resolvable and I have been bitten often enough by botched
merges on my end to do development on a different copy of Sage or a
different clone when merging patches. But I think we should at least
refuse to upgrade when there are not checked in changes in the repo
since that is a common cause of problems since some people apply
patches with patch and do not use hg to import patches.
Aside from the above recommendation to develop in a separate clone/
branch and then use a vanilla one to do the upgrading I see little we
can do to improve the situation unless there was a way to detect a
potential merge conflict before we merge. And as far as I know that is
not possible with hg. What we could do is to automatically clone sage-
main to sage-main-upgrade-3.2.2.alpha2 so that the user only had to
switch back to the previous clone, but that does eat up a lot of space
in the long term. So we could clone, upgrade the repo and if the
upgrade finished delete the old repo we cloned from and move the new
clone into its place. But that still doesn't catch bungled merges when
things to compile. In the end it is trivial to get back the original
repo by running "sage -clone $FOO --rec $SOME_REV" and trying over
again, so maybe just documenting more ways to get yourself out of a
failed sage-devel upgrade might be orthogonal to the desire to make
upgrade work better, but it will lessen the impact of such a problem.
> - Robert
Cheers,
Michael
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
