Does anyone still use branches? I used to always do a "sage -clone" right after building a test version, but since using queues I never do that. If I need to test something which affects more than the Sage library, notably a new version of an spkg, I just copy the entire build using cp -r, and work on that.
John On 9 February 2012 14:56, Keshav Kini <keshav.k...@gmail.com> wrote: > On Thu, Feb 9, 2012 at 01:45, William Stein <wst...@gmail.com> wrote: >> On Tue, Feb 7, 2012 at 9:57 PM, Keshav Kini <keshav.k...@gmail.com> wrote: >>> My $0.02. >> >> I disagree with what you wrote above. Perhaps you have a different >> impression than me of how Mercurial is used, given the relative sizes >> of our contributions to the Sage library. >> >> deep:hilbert wstein$ hg log|grep -i keshav|wc -l >> 9 >> deep:hilbert wstein$ hg log|grep -i wstein|wc -l >> 5368 > > Zing! Indeed, I talk too much and walk too little :) Hopefully this > will change as I gain more practical experience, and critically in the > case of the Sage library, more knowledge of mathematics... > >> This strikes me as hyperbole: "We currently get zero benefit from >> using a distributed version control system." > > OK, you're right, that's a bit of an exaggeration, even in the context > of benefit to collaboration. Certainly there are many local benefits > of using Mercurial over, say, Subversion for our source control, chief > among which I would count the ability to quickly make clones, or to > even ship a repository in our source distribution (and even our binary > distribution!) at all. This latter is important since it allows users > to revert code to a known good state, and just generally keep track of > their own code, I guess. > > Even when collaborating with others, there are some advantages of > using Mercurial over using nothing at all, such as the ability to > easily create patches against released code without needing to keep a > vanilla code directory alongside your sandbox directory... as is > nevertheless a practice suggested, strangely enough, to new developers > both by the developer's guide and tacitly by the fact that the concept > of "Sage branches" (no relation to Mercurial "named branches" or git > "topic branches") is so pervasive in Sage's scripts. > > I guess the main reason for "Sage branches" is to avoid needless > Cython recompilations that happen when you push and pop patches on > your queue a lot in one "Sage branch". I hope this can be fixed in the > future, perhaps by building VCS revision names into files generated by > Cython, and loading them using symlinks, or something like that, but > in any case I doubt a new developer will be modifying code that will > result in huge Cython passes... or is that another misconception? > > But in any case it is still true that we could be getting a lot more > benefit out of distributed version control than we currently are, IMO, > by ditching patches and using the history tree for live development > rather than as a dead changelog. > >> That said, picking apart what you write would be counterproductive, >> because I greatly appreciate that you are so motivated to help us with >> transitioning to more efficient workflows, git, etc., and I sort of >> want you to continue to believe what you wrote even if it isn't >> technically 100% true. :-). > > I would like to avoid being a mindless zealot if at all possible :) > But I'll defer to your judgment on the matter, haha. > > -Keshav > > ---- > Join us in #sagemath on irc.freenode.net ! > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
