SCM discussions in the GNOME community

Tue Sep 11 13:13:26 BST 2007

David Cournapeau wrote:
> Hendy Irawan wrote:
>> David Cournapeau wrote:
>>> I have myself tried bzr on repositories at least as big as gtk, with 
>>> several thousand revisions. My main grip with bzr performances is 
>>> network wise: it takes already something like what, 10 minutes, to 
>>> branch out bzr frommainline for me. And bzr size is by all account 
>>> negligeable compared to gnome: if you want to build basic gnome from 
>>> sources, how long will it take just to get the sources ? One hour ? 
>>> 5 hours ? More ? This is the main concern.
>>>
>>> My opinion is the following: I think bzr is pretty good (I don't 
>>> know much other DSCS outside arch), but has a pretty bad press 
>>> performance wise (this is totally unscientific, but almost everytime 
>>> I mentioned bzr with respect to some projects I am involved with and 
>>> know that bzr could handle them, this is one of the main concern). 
>>> My fear is that people are advocating bzr for projects where it will 
>>> not work well, and as such increase th bad press problem: having one 
>>> more blog article bzr is cool but cannot handle project foo is worse 
>>> than no article at all, I think.
>>>
>>> So before advocating it, I think it is important to see whether bzr 
>>> can handle a repository the size of gnome: if I want to build core 
>>> gnome from source repository, I need something like 160 packages 
>>> according to jhbuild. Let's say there are 1000 files per package, 
>>> each with 5000 revisions for simplification. How long does it take 
>>> to get the sources if they are all under bzr ?
>>>
>>> Cheers,
>>>
>>> David
>>>
>> I really want to know where (in what kind of projects) does "bazaar 
>> performance quite good".
> I think the main description on bzr's website is quite right: it 
> performs well on project with a few thousand files (I don't know 
> revision-wise, never had any problems with it for projects with 
> several thousand files and several thousand revisions; this does not 
> mean of course there are none, just that I have never hit them).
>>
>> I've been having about Bazaar performance locally. But anytime I want 
>> to "bzr push sftp://" it's NIGHTMARE. Does anyone ever have good 
>> results with this? Please let me know if you do.
>>
>> And my project isn't at all big. It's a 25 MB repository (Bazaar+du 
>> says) and it takes a few *HOURS* to simply push to Launchpad's using 
>> SFTP. (bazaar.launchpad.net/~ruby-id/bukuruby/trunk) And that's 
>> pushing FROM a speedy *server* that has abundant bandwidth (a few 
>> Mbps at least).
> This sounds really bad. As I said, I think network-wise, bzr still has 
> significant performance problems, but not as bad as in your case. 
> Maybe something is wrong somewhere in your setup ? If pushing to 
> launchpad was so bad, I think that nobody would use it, frankly. I 
> have not used it extensively, and do not remember such a problem 
> myself. Maybe you should fill a bug if you can reproduce the problem ?
>
> cheers,
>
> David
>
David... If you have not used it (I'm assuming it = pushing to Launchpad 
SFTP), would you help me diagnose this problem? (any list member is 
welcome to do so):

time bzr branch http://bazaar.launchpad.net/~ruby-id/bukuruby/trunk
cd trunk
time bzr push 
sftp://yourlaunchpad@bazaar.launchpad.net/~yourlaunchpad/bukuruby/trunk

It's a 25 MB repository, so it shouldn't be that bad if you have a DSL 
connection. Statistics:

ceefour at ojalanow:/media/prestige/home/ceefour/project/bukuruby/buku$ 
find | wc -l
1314
ceefour at ojalanow:/media/prestige/home/ceefour/project/bukuruby/buku$ du -s .
17444   .

So it's 17 MB plain (without SCM files), and about 1314 files. Most of 
my projects would be larger than this due to inclusion of numerous 
graphic files (i.e. web stuff) so 17 MB is a reasonable size, I think.

Let me know how much time it takes you to perform the former bzr 
commands I gave you. You need to use your Launchpad account (and SSH 
key) of course.

---------

If that one is too slow, maybe opt for a much smaller repo:

time bzr branch http://bazaar.launchpad.net/~ceefour/bukuruby/web
cd trunk
time bzr push 
sftp://yourlaunchpad@bazaar.launchpad.net/~yourlaunchpad/bukuruby/trunk

Statistics :

ceefour at ojalanow:/media/prestige/home/ceefour/project/bukuruby/web$ find 
. ! -path '*.bzr*' | wc -l
96
ceefour at ojalanow:/media/prestige/home/ceefour/project/bukuruby/web$ du 
-sc !(.bzr*)
84      app
4       components
72      config
4       db
8       doc
8       lib
28      log
232     public
4       Rakefile
8       README
64      script
40      test
24      tmp
8       vendor
588     total

96 files and 588 KB, shouldn't take long, should it? Well:

ceefour at ojalanow:/media/prestige/home/ceefour/project/bukuruby/web$ bzr 
merge
Merging from remembered location 
http://bazaar.launchpad.net/~ceefour/bukuruby/web/
|  0/0

This has been going for about *half an hour* already! On a 588 KB 
project? Come on!!!

UPDATE:

ceefour at ojalanow:/media/prestige/home/ceefour/project/bukuruby/web$ bzr 
merge
Merging from remembered location 
http://bazaar.launchpad.net/~ceefour/bukuruby/web/
bzr: ERROR: Working tree has uncommitted changes.

Sigh... after waiting about half an hour, it says this... Why didn't it 
tell me *before* attempting to merge?

There is one more problem with Bazaar:
* During the whole several tens of minutes (probably hours) of bzr 
merge/push, the working tree is locked
* If the working tree is locked, I can't commit, can't even "bzr st". 
Basically can't do nothing == can't work on my project.
* When the merge "finishes", it says my working tree is uncommitted.

It's a weird workflow, really, something I'm not sure if I can adjust to 
having to stop all my work _while_ pushing. Especially if the push takes 
more than "heartbeat time" (as SABDFL put it). :-(

-- 
Hendy Irawan
www.hendyirawan.com