On Thu, 2008-06-05 at 12:41 -0700, Robert Bradshaw wrote: > On Jun 5, 2008, at 11:36 AM, Glenn H Tarbox, PhD wrote: > > > First, a joke... since I can't tell jokes, I offer: > > > > http://changelog.complete.org/posts/698-If-Version-Control-Systems- > > were-Airlines.html > > > > Fortunately, I won't be getting in to the Distributed Version Control > > Systems (DVCS) wars here... but I had a question about how Sage uses > > Hg.. and from the answers, (and after checking to make sure I didn't > > have this entirely wrong) I figured I'd bring it forward. > > > > My question is: Why are we using "hg clone" when doing > > development? Hg > > clone, basically, copies over an entire repository to a new location > > which, from a DVCS perspective, is only done when creating the local > > repository on a machine. Doing a clone of a "local" repository, > > basically, doesn't make sense from the perspective of a DVCS. > > > > The idea as practiced in Sage is, I think, that one can maintain the > > "original copy" and "development" areas separately... but, says I, > > that's the entire point of DVCS in general, and Hg in particular. > > > > So, I propose there's a misunderstanding of Hg and clone vs. > > branch. I > > claim that branching is a trivial operation, switching between > > branches > > is fast, and that the entire point of DVCS is lost with the clone > > operation. > > > > Furthermore, by cloning, we need to maintain symlinks and have code > > specifically written to manage the updating of the symlinks to no > > advantage. Furthermore, it takes time and space and reduces the > > effectiveness of tools (e.g. branch visualization) for doing what I > > think the intent of the clone is. > > > > -glenn > > 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. > > 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. 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. > > 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. > > 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) > > That being said, I think a lot of people could benefit from using > branches more--especially those with slow/small hard drives. I didn't > even know about branching until I started using mercurial outside of > Sage. Queues are an alternative way of looking at things that a lot > of people like. > > - Robert > > > > > > P.S. Below is a broader discussion of the issue... > > > > WARNING: its entirely up to you whether you wanna get into this... and > > DVCS wars easily exceed politics and religion in the emotions and > > vitriol generated. > > > > The DVCS battle is currently between hg, bzr and git with hg giving up > > ground to bzr... and git being git > > > > <<<< opinion warning >>> > > > > IMHO, git is technically superior than the others but because Linus is > > such a "git" will likely not become mainstream... I personally believe > > there is a very intentional barrier to keep git users at the level of > > kernel hackers where folks pine for the day when you needed to be a > > hard > > core hacker to even dabble in linux... a cabal where only the anointed > > need apply. > > > > a shame, but such is life. > > > > to get an idea, check out Linus on git: > > http://www.youtube.com/watch?v=4XpnKHJAok8 > > > > and a much better follow up by Randall Schwarz which should have been > > titled: "What Linus means to say is:" > > http://www.youtube.com/watch?v=8dhZ9BXQgc4 > > > > <<< opinion end >>> > > > > So, the going-in assumption of any DVCS is that the developer > > always has > > a complete copy of the distro... whatever she wants to decide the > > distro > > is... although for most that will mean one of the "officially" tagged > > releases... and the DVCS system presents a specific "branch" to the > > user. > > > > To avoid terminology confusion: > > > > A "branch" is a particular path through the development tree. The > > tree > > has many branches at any point in time composed of the aggregate > > set of > > development activities of all developers and the merging which has > > taken > > place along the way throughout the DVCS spatio-temporal mesh. > > > > Some branches after a specific commit will be "tagged" as a release or > > as a specific starting point for a group activity to help coordinate. > > However, its critical to recognize that there is no central control > > in a > > DVCS... the importance of a tag or a release is only that to which the > > community assigns: a particular tag / user / repository is only > > important if you make it important. This is very much in contrast > > with > > CVS/SVN where there was a central managed system with clear lines of > > authority and permissions and security.... nope, DVCS is all about > > true > > meritocracy... I care about your branch cuz I trust you. In Sage's > > case, its when mabshoff or wstein or the other folks whom we all > > know... > > say so... because we trust them... not because they have the password. > > > > However, you can have both... since Sage cares about sagemath.org, it > > can be managed in such a way that a specific tag signed by the "usual > > suspects" means what we think it means. So, we have both kinds, > > centralized and distributed. Of course, one might argue that its the > > gpg signature that really matters, not sagemath.org... but I digress. > > > > To emphasize: DVCS allows untethered users complete flexibility to go > > off the reservation for very long periods of time... creating > > branches, > > committing changes etc... and allowing them to be merged back into ANY > > other DVCS repo within the DVCS mesh. Due to the magic of sha1 > > encoding, the paths are unambiguous... merging it all together if > > there's been no coordination is another matter... but that's a social > > not a technical issue. > > > > -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 > > > > > > > > > > > -- 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 -~----------~----~----~----~------~----~------~--~---
