On Mon, Dec 8, 2008 at 11:54 AM, Robert Bradshaw
<[EMAIL PROTECTED]> wrote:
>
> On Dec 8, 2008, at 1:56 AM, mabshoff wrote:
>
>> 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.
>
>
> We can detect whether or not a merge will be needed, just to a "hg
> incoming" and "hg diff" from sage-main to the newly unpacked sage-
> x.y.z spkg. If these are empty, it would behave as normal. Otherwise,
> it would either build somewhere other than sage-main, or (my
> preference) move sage-main to sage-main-backupN and install a
> pristine sage-main. Thus a full rebuild -ba would only be required if
> people edited their sage-main.
This is exactly the behavior that I, as an expert, would not want.
Since the upgrade command is currently aimed at experts (imho), maybe
this is an argument for having two commands:
sage -expert_upgrade
sage -upgrade
where the first is the current sage -upgrade command (except always
the *current* hg sage branch is upgraded), and the second is maybe
more what Robert is suggesting. The second would still have the big
warning about this being dangerous.
Of course, maintaining two types of upgrade command is more work, and
potentially confusing. Thoughts?
William
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
