BDFL decision of Python's DVCS

[David Cournapeau]

Andrew Bennetts wrote:
>
> I'm not sure we ever claimed that?
>   

I don't remember the details, but there were several sections where the
wording was not very clear (or my English deficient :) ). I remember at
least one section in the git vs bzr where I changed this (that has been
discussed on the ML some time ago).

>   
>> open source. I think this whole speed business is a bit overrated. I
>>     
>
> I agree.  Certainly our overriding goal isn't speed for its own sake, but to
> make a VCS that people love to use.  Being “fast” is a necessary, but not
> sufficient condition for a good UI, and being “fastest” isn't necessary.  People
> care about more than that, as, for example, Python's decision not to use git
> shows.
>   

In my understanding, in the case of python, people wanted to keep a
workflow as similar as SVN. I find the PEP poorly written - or at least,
it does not really show any advantage/weakness of each tool.

I know bzr and git fairly well - I can't see any difference between them
from the PEP, and why I would prefer git over bzr (or the contrary).

> We need to be “fast enough”.  Beyond that our efforts are better spent improving
> other aspects than speed.
>   

Agreed. Realistically, bzr will never be as fast as git - if people
can't stand commands which take > 10 ms to start doing something, python
can't be an option for a few years (before hardware catches up :) ).
Trying to compete on that aspect is a lost battle.

What remains to be seen is whether git will grow a more 'discoverable'
and user-friendly workflow. The need is there, with tools like repo from
android.

>
> To nitpick, bzr does do multiple branches in one "repository", although we use
> the terminology slightly differently.

I was using git terminology - IOW, branches are not visible in the fs.
This has significant consequences on the ability to work on several
branches at the same time, which is important for review and release
purpose.
>   We don't have a builtin way to do
> multiple co-located branches, though I think we'd like to change that... (with a
> bit of set up a treeless shared repository with many branches + a lightweight
> checkout is functionality quite similar, though).
>   

I don't think so. I think I mentioned this already a couple of months
ago - the multiple branch in one repository is not just a low level
thing in git: the ability to work on several branches at the same time
is deeply ingrained in the whole UI. If I want to see the difference
between foo 1.0 and foo 1.1 in two different release branches, I can
quickly see the difference in term of code, committers, per directory,
etc... Same for reviews. The UI for this is simply not there in bzr ATM.
Git really IS simpler than bzr (and maybe hg ?) for this. And git IS
less confusing because it does not use revno. How bzr can be used for
the following ?

git log foo_1.1  foo_1.2
git diff foo_1.1  foo_1.2

Given that this works for remote branches as well - where it can
potentially be very useful for review (I say potentially because I have
yet used this workflow with 'real' git, only with git-svn, which
complicated the matter a lot).

That's really the kind of things that almost nobody talks about, because
talking about speed is more obvious, and easier. But speed is 'trivial'.
That's not what differentiate the tools. And that does not unleash the
big potential that DVCS have for reviewing (which still is not really
clear IMHO - no tool get it 'right' yet, at least not the ones I have
used), with possible integration with bug-tracker and other tools.

I hope that once bzr is fast enough, discussion will move on the the
*interesting* problems and potentials of DVCS.

cheers,

David