Bazaar-NG vs. Mercurial -- speed comparison

[Alexander Belchenko]

Bryan O'Sullivan пишет:
> Alexander Belchenko <bialix <at> ukr.net> writes:
>> Hg designed for speed, Bzr -- for easy to use.
>> Probably it's very unconvincing argument to prefer bzr.

I forget this one: bzr have plugins support. Sometimes it's give 
incredible ability for experiments and implementation of new features.

> Actually, if it were true, then I think bzr would have a good piece of
> differentiation on that count.  However, hg is very much aimed at simplicity
> of use, too.  For similar operaions, hg and bzr even have identical command
> names and options.

Yes, and no. Basic commands looks similar as long as you don't go into 
detail's. And when you dive deeper in nuance you'll see that for some 
actions you need to use different mental ideology. It's not totally 
different but at least I'm personally looking at help of hg cannot 
figure out how to get log with list of changed files (similar to bzr log 
-v).

>> Hg has smaller source tree, smaller commands sets.
> 
> Of course you can interpret this as either good or bad.  I personally very much
> like the small command set that Mercurial provides.

I don't want to stick a label either `good' or `bad'. It's only the 
fact. But from this fact I'm as average python developer may conclude 
that your code should be easier and faster. And it's good. I like the 
KISS principle when I see real examples of their success.

But probably another side of the mentioned fact is that core of hg 
should be solid. And this might means that implementing plugins support 
(plugins written in python) could contradict main principles of hg.

And your `demand load' mechanism is really good.

>> Hg has worse windows support than bzr. Actually I don't find any
>> mentions that windows support is important to hg team.
> 
> It is very important, but it's also important to have core contributors who
> use Windows a lot, which I would be delighted if we had.

I can give you a little advice. You need to redistribute compiled 
ready-to-use C-extension (*.pyd) for your C-modules for different 
windows python versions (2.3/2.4).

There is really barrier for python enthusiast that want to hack your 
code and provide patches for Windows. Because microsoft policy is 
prevent to easy/free obtains C-compiler for their platforms. And Python 
2.4 use another C-compiler than Python 2.3. And Python restricted to use 
another C-compiler that differ from C-compiler that compile Python 
itself. Despite the fact that user can point explicitly what type of 
compiler he want to use, using non-native compiler cause very weird 
problems with C-runtime. And because bzr is pure python, I don't have 
any problems with hacking it on windows.

Another solution to avoid C-compiler dependency is to switch to using 
ctypes as alternative to C-extension. In this case hg probably could 
switch internally to using another interface between python and C, this 
leads to slightly slowdown in this case, but it is not fatal. Providing 
more alternatives to windows hackers you'll give them ability to easy 
establish try-and-hack process. They don't need to seeking compiler, 
install it, infinitely tuning it up to make python distutils happy. 
Simply download source (yeah, in zip archive), download dependencies and 
go. Even without compiler.

Second advice about windows-friendliness: if you make a cool GUI 
interface ensure that it will works on Windows. Per example, for bzr 
there is (brilliant) plugin named bzrk. But it require pygtk 2.8 and 
pycairo (I don't remember exactly version number). You will not be 
surprised if I say that this dependencies yet not ported to windows, and 
bzrk on windows cannot be used?

--
Alexander