On Thu, 2008-06-05 at 14:03 -0700, Robert Bradshaw wrote: > On Jun 5, 2008, at 1:10 PM, Glenn H Tarbox, PhD wrote: > > > > > On Thu, 2008-06-05 at 12:41 -0700, Robert Bradshaw wrote: > >> I'll jump in and give some reasons that (for Sage) clones have > >> advantages over branches. > >> > >> 1) Sage has a non-trivial build process for Cython files. When a .pyx > >> file is changed, the .c file needs to be regenerated, as well as .so > >> file. Changing a .pxd file can result in a cascade of .c/.so files > >> that need to be regenerated. Clones allow one to keep all these auto- > >> generated files around without having to commit them or (potentially) > >> re-compiling every time one switches branches. This I think is the > >> main reason. > > > > This should all be manageable with proper directory organization or > > build rules... as Sage progresses, a mechanism to understand that a > > derived type to one system is a source type to another will need to > > exist regardless. > > Sage already has such a mechanism. The point I was trying to make is > that it works better with clones than with branches, but I apparently > wasn't clear enough. Suppose I make a branch and edit the file > integer.pyx. Now integer.c is auto-generated from this. Every time I > switch back and forth between branches either integer.c needs to be > regenerated (which will be automatically detected as integer.pyx will > have changed due to the branch switch) or hg needs to update > integer.c to the right copy (either because it's tracked, a bad idea > since it's auto-generated, or magically from some other place). > Depending on how many files were edited, and how high up the > dependancy tree they are, all of this re-generation and re- > compilation could be expensive. > > With a clone, there are two copies of integer.pyx in separate > directories, sitting next to their respective integer.c files, and > switching back and forth just works.
Well, you kinda have me on this one. Generally, folks don't toggle between branches with sufficient frequency for this to be an issue, and I definitely agree that recompilation can be non-trivial. If this is the use case, then I'd say that some form of replication is called for. I'll look through the docs because there would be utility to having a common underlying repository with different branches instantiated under different parent directories. This would provide some level of unification in that you'd be able to see all the branches and use the DVCS gui tools etc. If not, then I'd agree that cloning is for you. However, I'm not entirely comfortable with the dynamic symlink. I'm guessing that relatively few folks need to do this type of branch toggling... but I could be wrong and the extra disk space for a full up replication probably isn't an issue. An alternative would be an environment variable pointing to the sage subdir as opposed to a symlink. BTW, it isn't that I have an issue with symlinks... but I'm trying to nail up PyDev and this strategy does cause some issues (of course, I am the exception here so I'll get around it... but my guess is this is going to come up with increasing frequency...) > >> 2) The refereeing process of Sage means that almost every changeset > >> gets exported as a patch, posted to trac, then at some future date > >> merged into the "official" release. This round trip outside of > >> mercurial sometimes leads to extra conflicts/merges when pulling on > >> top of ones personal repository when doing, for example, sage - > >> upgrade (though usually mercurial is pretty intelligent about > >> figuring these things out). > > > > This should be independent of whether you have a clone or a branch. > > With a clone I simply abandon that clone once everything in it gets > merged upstream, which goes to point (4) below. Maybe I'm just odd > that way though, and a relatively quick release cycle makes this > possible. with git its just git -D branch_to_kill but another post (cwitty) indicates that Hg doesn't have this option so, that's badness in Hg cuz this capability is necessary. > > > Again, the entire point of a DVCS is to manage this type of activity. > > > > In terms of using patches as a transport, its just a transport. I > > think > > it would be cleaner to import the branch as a branch and have final > > merges into mainline branches controlled using current practice. > > Patches in trac are, IMHO, clumsy although in practice it probably > > doesn't matter much. > > > > I'd also say that the patch approach is more appropriate to SVN style > > controls than DCVS controls. > > I agree that posting patches on trac is technically a clumsy way to > go about things, but in terms of the socially aspect of coordinating > things between the author, referee, and release manager it works very > well, especially as most trac tickets are small, relatively self- > contained, independant additions. I am making no claims about process... just that the technology lends itself to greater flexibility. Clearly, there needs to be a process for blessing various patches / merges / changes. However, there are nicer ways to achieve this goal other than patches in trac. In particular, if there were a core repo with various branches submitted but not merged, it would allow much better visibility... not to mention that small groups could use this strategy amongst themselves in a fashion consistent with the coordination with the mother ship. > > >> 3) Clones are conceptually easier to understand and harder to mess up > >> (by, for example, doing working on one task without switching to the > >> right branch first). I am not saying that virtual branches are too > >> difficult for anyone to figure out, but clones are even easer for > >> getting started with the system. > > > > I'd counter by saying the need for symlinks more than offsets any > > advantage and more often than not hides where you are anyway... > > when you > > do a pwd after traversing a symlink it doesn't indicate the true > > directory. > > Ah, but I never actually go into the symlink directory. I always cd > into the clone I intend to work on. yes, I've seen this mentioned elsewhere. Makes sense. > > >> 4) It's easier to abandon the history of a clone, both for hopelessly > >> broken development efforts and refereeing of other people's patches. > > > > git branch -D badbranch > > > > as opposed to the usual > > > > git merge developmentBranch > > git branch -d developmentBranch > > > > (btw, I'm a git user... I'm sure there's something similar in Hg) > > One things about hg is that it really doesn't like it when you try > and throw away history. I hope there is an equivalent command--if I > used branches rather than clones I'd have certainly needed it by > now :-). As it is now, I just do an rm. Yea, Hg must be fixing this... I'm a bit surprised this isn't in there. > > I think both of these last two points are about how much is explicit > in the file system (potentially a waste of disk space) or not > (worrying more about the dvcs state). This is probably a matter of > taste. I am glad you brought this up though, branching can be used > too and should be brought up in the developer docs. I'd guess that branching should be brought up first as, again, IMHO, the bulk of the use cases for the common developer are handled better by branching... but clone obviously needs to be discussed for the "need to toggle between branches a lot" case. -glenn > > - 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 -~----------~----~----~----~------~----~------~--~---
