by popular demand, I've reluctantly agreed to bring up hg clone yet again because I think that beating a dead horse is under-rated.... you can never beat a dead horse enough!!
Turns out, there are 2, and I'm pretty sure, only 2 reasons for the use of clone over branch.... 1) Deleting History - You can't remove a branch or points along a branch... so its better to clone so you can wack the entire directory as though nothing happened 2) Branch Toggling - because compiling cython can be expensive, if you toggle branches using Hg, you need to recompile at each toggle. Basically 1) is an Hg specific "feature" which speaks to inferior architecture (and its inevitable demise given the alternatives). However, it turns out you can get 1) without cloning "before the fact" So, you branch instead of clone... forge ahead, wildly adding changes and committing.... and are just shy of proving the Riemann Hypothesis, when to your horror, you discover that some of your underlying analysis might have been flawed. Fortunately, you've told nobody of your activities and figure, if I can just roll back to a point in time... but not all the way back, everything would be fine and you can keep your job, get tenure etc. Turns out, you can do that with Hg... USING CLONE!!! So, what you do is clone the repo to a specific revision... which will create a clone without any of the history beyond the revision you indicate. And, 2) is a corner case for a relatively small percentage of developers. To recap, developers, for the most part, stick with a single branch. The good news is that clone will work for those unlucky few for whom toggling is a way of life. So, my conclusion is that we should be using branch instead of clone as the general development strategy with clone limited to those who are working specific types of problems and need to deal with it. All this leads to one of my original points: We might want to consider using Hg as designed... Heretic!!! OK, what Glenn means to say is: I suggest there's a better way to manage the sage development process using the features of Hg. Realizing that Sage's current process "works" and there's undoubtedly a significant amount of debate ahead of us, the Bolsheviks of the finance / dsageng activities are going to use an alternative (Hg's intended) approach of branching and merging as the sole mechanism for distributed development and version control Accordingly, there will be an hg server with various branches associated with the development activities. Synchronization with Sage distributions will occur with patch sets or using an out-of-band coordination with the Central Committee. How to view / use / contribute to the finance / dsageng activities will be explained on the wiki and announced in a few days once the infrastructure has been instantiated. -glenn -- Glenn H. Tarbox, PhD || 206-494-0819 || [EMAIL PROTECTED] "Don't worry about people stealing your ideas. If your ideas are any good you'll have to ram them down peoples throats" -- Howard Aiken --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
