Re: [sage-devel] Checking out old branches

2016-11-22 Thread Jeroen Demeyer
On 2016-11-22 18:35, Robert Bradshaw wrote: What I'm not following here is how this is not the correct behavior, nor how hashes would help other than adding complexity (e.g. one must store the hash of a.pxd inside b.c). Also, manually setting timestamps would risk incorrect builds (remember the

Re: [sage-devel] Checking out old branches

2016-11-22 Thread Robert Bradshaw
OK, let's consider the following setup: we have three Cython modules, a, b, and c, and b cimports a, so we have (at least) three files a.pyx a.pxd b.pyx c.pyx Having just built sage, we also have a.c b.c c.c with *newer* timestamps than any of the above. Now we switch branches (forward,

Re: [sage-devel] Checking out old branches

2016-11-21 Thread Erik Bray
On Fri, Nov 18, 2016 at 8:18 AM, William Stein wrote: > > Ideas: > > > What about changing Cython to optionally use sha1 or md5 hashes instead of > timestamps? I've had this thought as well--it would be fairly straightforward to output a list of hashes for all Cython sources

Re: [sage-devel] Checking out old branches

2016-11-20 Thread Volker Braun
I think thats backwards, you want to control timestamps and the answer is to script some convoluted way of merging branches for very specific circumstances? Why not control timestamps? You really need to a) save timestamps and b) restore timestamps for unmodified files. To be reliable a)

Re: [sage-devel] Checking out old branches

2016-11-20 Thread Dima Pasechnik
It would be great is at least the developer docs get an short explanation of how to do this with plain git. (or at least *here* :-)) Deja vu for me: I posted https://groups.google.com/d/msg/sage-devel/hea2Ncbki7Y/cV47AWjDBwAJ a while ago, and now I don't even remember how exactly 'git

Re: [sage-devel] Checking out old branches

2016-11-20 Thread David Roe
So, back to the git worktree plan? I had it mostly working before switching to this approach. If $SAGE_ROOT is /path/to/sage-7.4, it checks out to a sibling folder /path/to/sage-7.4_merge_tree. Automating it is a bit more complicated though; if the merge fails and the user has to correct it

Re: [sage-devel] Checking out old branches

2016-11-20 Thread Volker Braun
Thats a wrong-way merge and is confusing if one ever wants to understand the history of the ticket. The convention is that the feature branch is first, and you merge in dependencies. On Sunday, November 20, 2016 at 2:31:57 AM UTC+1, David Roe wrote: > > I've implemented a new git-trac

Re: [sage-devel] Checking out old branches

2016-11-19 Thread David Roe
I've implemented a new git-trac command at https://github.com/sagemath/git-trac-command/pull/26. I ended up not using git worktree at all. Instead, the command creates a new branch from develop, and merges in the changes from the old branch. I know that there's been some discussion that merging

Re: [sage-devel] Checking out old branches

2016-11-19 Thread David Roe
On Sat, Nov 19, 2016 at 7:12 AM, Jeroen Demeyer wrote: > On 2016-11-19 11:23, David Roe wrote: > >> I mean that even if I checkout develop again before building Sage, it >> still takes a long time. >> > > You mean something like > > - checkout old branch (but don't build

Re: [sage-devel] Checking out old branches

2016-11-19 Thread Jeroen Demeyer
On 2016-11-19 11:23, David Roe wrote: I mean that even if I checkout develop again before building Sage, it still takes a long time. You mean something like - checkout old branch (but don't build it) - checkout new branch - build Sage That's a known issue, but it's certainly not

Re: [sage-devel] Checking out old branches

2016-11-19 Thread David Roe
I mean that even if I checkout develop again before building Sage, it still takes a long time. David On Sat, Nov 19, 2016 at 3:35 AM, Jeroen Demeyer wrote: > On 2016-11-18 08:12, David Roe wrote: > >> If I checkout an old branch (say, from one or two versions of Sage

Re: [sage-devel] Checking out old branches

2016-11-19 Thread Jeroen Demeyer
On 2016-11-18 08:12, David Roe wrote: If I checkout an old branch (say, from one or two versions of Sage ago), it essentially forces a rebuild of all of Sage, even if I think better of it and checkout develop immediately. What exactly do you mean with "even if I think better of it and checkout

Re: [sage-devel] Checking out old branches

2016-11-17 Thread William Stein
Ideas: What about changing Cython to optionally use sha1 or md5 hashes instead of timestamps? Or write a python script that just sets the time stamps back on all the files that haven't changed. (Run it before and after...). On Thu, Nov 17, 2016 at 11:12 PM David Roe

[sage-devel] Checking out old branches

2016-11-17 Thread David Roe
If I checkout an old branch (say, from one or two versions of Sage ago), it essentially forces a rebuild of all of Sage, even if I think better of it and checkout develop immediately. The rebuild is a consequence of the fact that Cython builds based on timestamp and all of the files have been