On Jun 6, 9:07 am, "Glenn H Tarbox, PhD" <[EMAIL PROTECTED]> wrote:
Hi Glenn, > OK, so I just couldn't help myself... forgive me this transgression. (I > know I'm gonna regret this in the morning :-) Yes, flame thrower on ;) [just kidding] > 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 I don't doubt git is "better" for some things, I myself actually think git does a couple things better than hg, i.e. permissions for files and zero byte files are problematic issues with hg. But any kind of switch requires a lot of work and many people's skill set with hg will need to adapt. I think that git needs to be substantially better than hg to justify a switch and I don't see that. Hg is python, git isn't. The alleged complexity of git can be hidden, but at the end of the day the existing work flow does work well and any kind of such a fundamental change would cause disruptions. Since tools to move repos and patches from one DRCS to another exist I see no reason for somebody like Glen who prefers git to use it and then in the end submit hg patches. My workflow with hg has adapted and I expect that with ques and alike things Glenn's workflow can also adapt. > 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. Well, checking everything into a repo will basically double the compressed size of Sage for the inital download. As a trade off future upgrades would requite less bandwidth. But updating something like Sage from a single git repo would require an insane amount of CPU cycles since we need to deal with tens of thousands of files for example [remember when the kernel.org git server got slow because the files did no longer fit into RAM and the directory lookup time killed performace]. And that leaves all kind of consistency issues, i.e. "my upgrade broke, what should I do?" With an spkg we can use the md5sum to check and just delete and redownload. git and hg offer consistency checks, too, but that again requires a lot more CPU cycles to run. There are servies like gitweb that could potentially host such a repo and if anybody wants to put that up feel free to do so, but we want to control every aspect of Sage and its distribution and that would require hosting the repo ourselves [at least a master]. This suggestion has come up before and while it sounds tempting I consider it impractical. > > 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. Yes, but my imaginary aunt Tilly prefers to download one file and then to execute make to build Sage. As is an upgrade does not require anything beyond the ability to get a the new tar file onto the box and then after you unpack the tar file into the right directory one "make" will upgrade the build without the need to access the net [the normal "-upgrade" mode does not work that way obviously]. The same can be done for a proposed giant repo, but one of the leading principles of Sage is KISS and one giant repo is not KISS any more. Feel free to set up such a repo and prove me wrong, but I doubt it will ever be the default mode we build Sage. > > Tim Cheers, Michael > -- > 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 -~----------~----~----~----~------~----~------~--~---
