John Hunter wrote: > On Jan 7, 2008 2:37 PM, Eric Firing <[EMAIL PROTECTED]> wrote: [...] >> All this brings to mind the discussion taking place over the last week >> on the numpy list regarding switching from svn to bzr or hg. >> http://thread.gmane.org/gmane.comp.python.numeric.general/18130 >> (I have been using hg locally for a couple years, and I like it.) The >> motivation is the greater ease of branching and merging with distributed >> VCS systems in comparison to SVN. In the numpy list discussion, it >> sounds like all participants except Travis favor making the switch. > > I'm personally -1 on this. I prefer to keep things as simple as > possible and do not see the need for a lot of branching, though there > is clearly a need for some. svn is the standard version control > system and has the best install base (now on OS X and all linux > systems), making it easiest for users to get checkouts. If numpy, > ipython and scipy all decide to move, I would probably be inclined to > go along with it for consistency between these packages, but I > wouldn't be leading the charge. I have never felt the need for a > distributed version control system, personally, though some swear by > it. It is probably because mpl has always just had a trunk with no > branches, and I'd like to stick to that as much as possible,
John, I understand your points, and this is not something I am going to push, but I suspect that over the next year or two there will be a migration of numpy, ipython, and scipy. Certainly there is no need for us to lead, and it might be downright foolish for us to try to do so. My sense, however, is that a good DVCS is something like python itself--the majority of people who seriously try one get hooked. The point of the DVCS is not to facilitate long-term branches; it is still normal to have a single official version. Instead, what a DVCS does is to make version control easy to use locally, regardless of whether one is connected to the net or not; and to use VC while experimenting with changes. A full working repository (and a very fast one at that) is always available. It is extremely fast and cheap to make a clone for experimentation; if things work out, the changes can be propagated back to the main repo, either as they were made initially or by first generating a single clean patch; and then the experimental repo is deleted. I have never used hg as a central repo in a project with more than two developers (my helper and me), so I don't know exactly how it would be set up, how authentication would be handled, etc. for projects like numpy and mpl. What I do know is that using hg--and consequently having repos for our software on all the ships we work with, and on our laptops when we travel--has been a big help. I suspect that if you tried it, you would find yourself liking hg for entirely private use on work for your employer. Eric > > Michael, how onerous was it for you to do the merges using svn -- this > seems to be the most significant problem with svn in my reading of > David's summary. > > JDH ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
