Re: [matplotlib-devel] moving to the transforms branch

[Andrew S. <str...@as...>]

Something I haven't seen addressed on the numpy list (or here) is using 
hg or bzr to mirror an svn repository. What would be the added advantage 
to the project of using a DVCS if all the DVCS-ophiles would simply sync 
the svn tree?

Eric Firing wrote:
> John Hunter wrote:
>> On Jan 7, 2008 2:37 PM, Eric Firing <ef...@ha...> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel