On Tue, 2008-06-24 at 21:08 -0700, Robert Bradshaw wrote: > On Jun 17, 2008, at 4:13 PM, Glenn H Tarbox, PhD wrote: > > > 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!!! > > I use clones a lot because I often work on (low level) .pyx files, > but I agree that many people would be better served by branching, > which one can do now, and this should be discussed in the user > manual. Mercurial queues seem to be very nice too (I'm going to be > using them more) and mesh well with the referee process.
Unfortunately, upon further review and lots of checking on the lists, turns out that Hg "named branches" are not good and are being reconsidered by the mercurial folks. They are very much not the same thing as bzr or git branches... and it took a while to understand what was really going on. Anyway, I have lots of thoughts on the subject but I'm going to let them bake for a while. Our smaller crew will experiment with a few approaches and report back. Basically, we'll have a repo for each developer where repo will mean 'set of clones' each with branches. Under the hood I'll use a little dark magic to make goodness happen and maintain a useful view of the state of development as a single Hg repo with well named branches. The state will likely appear more linear than will actually be happening, but the various tips and heads of the branches of the central Hg repo will be correct... just a little history "adjustment" along the way All of the repos will be published to central sites on a consistent basis. Some branches will be named as "working" meaning anything goes... We will all push on a regular basis regardless of the state of the code... and use naming conventions to indicate stability. In my case, my published repo is the mechanism I use for internal code distribution... so the granularity is very fine indeed... full of bugs and silliness... > > > 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. > > Do you have a link to the aforementioned wiki? http://wiki.sagemath.org/GlennTarbox/HgDevelopment > > - Robert > > > > -- 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 -~----------~----~----~----~------~----~------~--~---
