BDFL decision of Python's DVCS

[Jurgen Defurne]

On Tue, 31 Mar 2009 12:47:41 +0000 (UTC)
Lalo Martins <lalo.martins at gmail.com> wrote:

> quoth Russel Winder as of Tue, 31 Mar 2009 07:48:38 +0100:
> > The problem here is the "Hg has a strong
> > following among Python developers and few detractors, while few (except
> > Canonical employees) seem to like Bzr."  This one sentence has the
> > potential to be the nail in the coffin for Bazaar unless there is a
> > concerted effort to make it clear that his impression is wrong, and for
> > him to publicly retract it.  He doesn't have to change Python's switch
> > to Mercurial, that is not the issue.  The issue is that this
> > mis-interpretation of the state of usage of Bazaar will be treated as
> > fact such that Bazaar will become a Canonical internal tool.
> 
> I don't think there will be a retraction, and neither I see how we (the 
> community) can make it clear that his impression is wrong.  For a very 
> simple reason: it isn't.  It's absolutely true.
> 
> Now, I'm not a Canonical employee, and neither are you.  But go around 
> the net looking for people evangelising, promoting, or even blogging 
> (positively) about bzr.  You'll find most of those work for Canonical, or 
> have worked at some time in the past.
> 
> (I kind of suspect that is *partially* because Canonical is very willing 
> to hire good Bazaar developers/evangelists, but don't quote me on this.  
> It's also the case that Bazaar is a bit of an acquired taste; use it for 
> a few weeks, even if forced to at work, and you won't want anything 
> else.  So that may account for Canonical (or ex-Canonical) people who 
> weren't originally fans to become big enthusiasts.)
> 
> So no point in trying to deny what is true :-)  It would be more useful 
> to dispel the notion that it's a Canonical-only tool, or even Canonical-
> centric.  But I don't know how to do that, sorry.
> 
> best,
>                                                Lalo Martins
> -- 
>       So many of our dreams at first seem impossible,
>        then they seem improbable, and then, when we
>        summon the will, they soon become inevitable.
>                            -----
>                   http://lalomartins.info/
> GNU: never give up freedom              http://www.gnu.org/
> 
> 

I want numbers, numbers, numbers. I have a code base that I would like to manage using an open source tool, consisting of 33000 objects (files and directories), organised in 47 components (nested trees), with a size of about 2 Gb. Around 100 developers need to access this daily. I tried subversion and bzr on this codebase (but not a recent bzr, was probably 1.5 or something like that), and I think that bzr with its 1.9 format has the capacity to deliver in the future what I need.

Looking at other VCS's, notably git and Hg, it did not seem that they delivered other features I need. E.g. I can set up a central repository for bzr which can contain all nested trees, but for git you can only set up one central branch and as far as I found, all other 46 components need to be different branches. In Hg I haven't even found evidence or documentation that there was something available like nested trees or svn:externals.

Doing a test with subversion showed me that it was too slow, and with a code base which needs many merges, a potential maintenance nightmare.

Regards,

Jurgen