On 26 Aug., 05:44, Keshav Kini <keshav.k...@gmail.com> wrote: > Here's how I think upgrading should work: > > Don't check for cleanness in repos. > Pull from the new SPKGs' repos into the current installation repos. > Do *not* merge. > `hg update -c tip` in each of the current installation repos; save resulting > messages (in a file, say) to display at the end of the upgrade process > because users need to see it. > Done.
That's [IMHO] ok for true upgrades, but totally inconvenient for rebuilds, especially those indirectly triggered by dependencies, so we'd have to introduce some other "flag" (env var setting) for this. > This way after sage -upgrade you will have a totally clean new version, but > any modifications, commits, pushed patches, etc. you had before will be > lying around in other branches (other heads). If you want to merge these > changes, you should be doing it yourself, and not have it done during some > huge upgrade process where everything is flashing by. It is very > disconcerting to do `sage -upgrade` and then suddenly 15 minutes later have > kdiff3 pop up with some random files in it! > > If you had uncommited but tracked changes in the directory when you tried to > upgrade, you would see an error message from hg update -c tip at the end of > the upgrade process, as described above, which would tell you to go fix it. > And most importantly this would not cause errors due to *untracked* files > sitting around, as we have seen above. Where? In the repos' root directories, or all in, say, $SAGE_ROOT/ upgrade.log? Ceterum censeo there should be a way to prevent switching back to the "main" Sage library branch upon rebuilds (reinstallations), just for development / testing. -leif -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
