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. - Robert --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
