Thanks for the further explanation.
On 9/22/07, William Stein <[EMAIL PROTECTED]> wrote:
>
> On 9/22/07, John Cremona <[EMAIL PROTECTED]> wrote:
> > My own recent hacking, which rather foolishly has been done *without*
> > first creating such a new branch, involves two files covered by
> > hg_extcode and one covered by hg_sage. Would the right way to have
> > started this process have been to do this
> >
> > hg_sage.clone('hackbranch')
> > hg_extcode.clone('hackbranch')
> >
> > with some sensible name replacing 'hackbranch', but with the same name
> > for both (for sanity rather than necessity)?
>
> Yes that would have been sensible. However, hg_*.clone is only
> _implemented_ for hg_sage. Moreover, and this is very important,
> when you upgrade with "sage -upgrade", it will overwrite changes
> you make to hg_extcode.
So I just realized *!&*&! and am hoping that my emacs backup file is
not so out of date.
As a warning to others: when you get back after a trip and find that
there's a new version of Sage to upgrade to (and it would have to be a
very short trip for that not to be the case ;)) think first!
This is completely a NotYetImplemented
> issue. These are trac tickets 546 to 548. Also, having branches
> for the other repositories is potentially much more complicated
> than for the hg_sage repository.
>
> > (2) Secondly, now that I have done various hg-*.commit() commands, I
> > have ended up in a mess after the latest upgrade, so what I want to do
>
> You should only have a mess in hg_sage, since it's the only one
> that does a merge.
>
True
> > now is revert everything to the official files (after making sure I
> > have kept copies of my hacked files), then start my branch as above,
> > then move the hacked files into the branch directories.
> >
> > How do I do this reversion (apart from downloading a complete fresh
> > set of sources, which perhaps would be safest)?
>
> Do that.
Doing it now...
>
> > Apologies for asking questions which must seem stupid to most
> > sage-devel readers!
>
> They aren't stupid.
>
> Given the current status of implementation of cloning stuff, etc., if you
> are doing a lot of development to Sage, it is best to do the following:
> (1) Have one completely copy of Sage that you do not upgrade regularly,
> where you do all your hacking, and
> (2) Have a working plain copy of Sage that you do upgrade. Then after
> upgrading that plain copy, you can pull your changes from 1. E.g.,
> hg_extcode.pull('/path/to/1's/extcode').
>
OK -- time to get organised, I see!
John
> I would like merging, etc, i.e., track tickets 546 -- 548 to get
> resolved very soon.
> Hopefully I can do that before the next Sage release.
>
> -- William
>
> >
>
--
John Cremona
--~--~---------~--~----~------------~-------~--~----~
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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~----------~----~----~----~------~----~------~--~---
