OK, so I just couldn't help myself... forgive me this transgression. (I know I'm gonna regret this in the morning :-)
I think Sage would benefit from git. Its simply better and I think is gonna win overall even with the seeming efforts made by the git folks to torpedo its adoption. Truth is, nice front ends simply don't win out over a comprehensive hardended core. the bzr folks might have some heft... but I'm bettin' on Linus... and Hg will stay around but I don't see it growing beyond its current project base. As I thought about this a bit, I wondered... just how hard would it be to have "both kinds" while we showed how it would work. I've done this before with SVN and it worked ok. The idea is, "do git also". So, we leave everything as it is... but put a parallel git repo on top of the hg repo. OK, its nuts, but lets think about it. We could maintain a separate tree if need be, but I think the main tree might work as well. I need a few hours to think about this... probably makes sense to keep things separate to minimize breakage perhaps... hmmm... (and there are tools for hg2git... probably the other way as well) We create a git sage repo. As changes are made to the tree through hg, we do checkins with a branching naming strategy we decide on. Git folks could grab code with the usual methods. Tarballs can be automatially generated using gitweb (i.e. no work required). Gitties could submit patches via the usual methods including the email diff patch strategy. Generating hg patches consistent with the current method is easy and could be scripted... The thought is, particularly after getting feedback from the power branch users (robertw, cwitty, gfurnish, perhaps others), git could be very useful. Normal users could use git or hg or download tarballs... With a couplea hours thought once we're comfortable, sage-esque strategies for providing sage-ipython commands to control git could easily be added... This being said, I guess it needs to be decided whether this is worth it or not. Hg is solid and widely used... There is a threshold to utility. OTOH, if git is not going away (which it won't unless linux goes away) and its somewhat better, sooner is better than later. And, I'll emphasize a point which might have gotten buried in the thread on this subject. One characteristic fairly unique to Sage is the "everything including the kitchen sink, the plumbing, the water supply, the plumber, lighting and an interior decorator" approach to providing a distribution. most git complaints have to do with learning git (the discussion about plumbing vs porcelain) ... but, I suggest that we can hide virtually everything from the users who could care less by employing the general Sage approach of "wrap everything". git_sage would be the porcelain for Sagies. I have other thoughts about segmenting the code with subprojects but I need to know more about the internals there. but I wanna think about them a bit. But I think this would be relatively easy and probably well worth it. -glenn On Fri, 2008-06-06 at 02:47 -0400, root wrote: > One unmentioned feature of a git-based Sage archive is the ability > to pull a guaranteed-correct tree from history. This is not possible > using CVS or SVN. I am not sure about bzr or hg. > > Suppose you work on Sage-3.0.2 and it has an spkg, say SymPy at 3.3. > Suppose both Sage-3.0.2 and SymPy are held in different git repos > somewhere on the net (e.g Sage in sagemath.org, sympy in sympy.org) > > Now suppose the world moves on to Sage-3.1 and SymPy goes to 4.0 > > You can set up Sage so that if a user does a git-pull on Sage-3.0.2 > the "make" procedure can git-pull the correct tree (3.3) from sympy. > Since the git repo tree nodes are all uniquely labelled by a 40 bit > hash code you can be certain you got exactly the right sympy build. > > The advantage is that you would no longer have to have any spkg > code that contained sympy. And if I don't use sympy I don't need > to download it. > > Note that, in general, I very much like the fact that I only do > one tarball download, type "make" and it "just works". But the > latest DCVS tools support functionality that was not possible > using CVS/SVN. > > Tim > > > > > -- 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 -~----------~----~----~----~------~----~------~--~---
