Some bzr newbie comments (somewhat long)

[John A Meinel]

Jens Lund wrote:
> Hi
> 
> I am quite new to bazaar-ng (and distributed version control), and have only 
> been making a few experiments during the last 2 weeks, so please bear with 
> me if the following comments seem obvious and you have already discussed 
> them at length :-)

First, I would like to thank you for your feedback. It is always nice to
get response from people who are starting out.

> 
> First of all, I would like to congratulate you on the really, really easy 
> start and easy learning curve: given I had Python and cElementTree already 
> installed (Ubuntu 5.10), then installing bzr was a matter of 1) download 
> tar ball, 2) unpack tar ball, 3) make a symbolic link. It took at most 3 
> minutes. Another 5 minutes and I had versioned my first files and started 
> to making branches following the easy to read IntroductionToBzr/Tutorial! 
> That is really great work! Congratulations! (And in addition it seems like 
> a no brainer to publish your own branches even though I haven't done this 
> yet.)

Actually, if you have Ubuntu 5.10 there is an older version (0.6) in one
of the apt repositories. You might have to go to 'Universe', I don't
remember where it was.

> 
> Now, a couple of comments that will hopefully help improve bzr/bazaar-ng in 
> the future:
> 
> http://www.bazaar-ng.org/ links to 
> http://mccormickit.com/bzrweb/index.py/repositories for viewing bzr 
> branches on the web. I have not seen this link work during the last weeks 
> so it should probably link to http://bazaar.canonical.com/WebInterface 
> instead. A non working link on the front page gives the wrong impression.

Martin, can you fix this? I agree, main pages should not have broken links.

> 
> Performance of "bzr branch http://bazaar-ng.org/bzr/bzr.dev" is very, very 
> poor. I am on a rather old 400 MHz Pentium machine, but doing "bzr branch 
> bzr.dev bzrtest" locally takes
> real    2m13.153s
> user    1m2.054s
> sys     0m7.494s
> while doing other stuff. Just downloading the 37MB for bzr.dev (by e.g. 
> "rsync -av bazaar-ng.org::bazaar-ng/bzr/bzr.dev bzrtest") takes
> real    2m48.159s
> user    0m2.048s
> sys     0m9.523s
> (there is still some problems with permissions on at least 
> bzr/bzr.dev/bzrlib/lsprof.py that generates an error.) However, doing "bzr 
> branch http://bazaar-ng.org/bzr/bzr.dev" takes *a lot longer* than 1 
> hour... I suspect you are somehow making new network connections all the 
> time or something similar, and you might already be aware of this as 
> indicated on http://bazaar.canonical.com/BzrTips. Of course this should be 
> fixed (and I am sure you will), but in the mean time I suggest making a 
> comment in the tutorial that it might take a long time as  
> http://bazaar-ng.org/bzr/bzr.dev is used as an example of a remote branch.

We are working on several ways to speed up http connections. (using
pycurl, changing file formats, etc). One thing that you are running
into, is that you are actually CPU limited. With an http connection, bzr
has to download and parse all of the information about each revision, so
that it knows what other files it needs to download. We have been
probably focusing more on http latency so far, but there are a couple of
changes which should help CPU as well.

I do know that bzr (especially in its current form) is targeting faster
processors. I have a server which is a 700MHz machine (used to be 450
for quite a while). And I use bzr on there fairly often. But it isn't
super snappy.

Hopefully as bzr stabilizes there will be more opportunity for
optimizing for slower machines.

> 
> User interface for rename, move, mv: comming from unix experience it is not 
> clear what the difference is between rename, move and mv. Isn't it all the 
> same? I haven't looked at the code yet, but the help texts doesn't really 
> make the difference clear --- on the contrary the help text for mv 
> explicitly mentions renames and moves, the help text for rename gives an 
> example of a movement and points to move for what the rename example just 
> did, etc. etc. I suggest cleaning up this interface to one command (mv?) 
> that can handle all cases of renames and movement of 1 or more files, and 
> then remove the two redundant commands from the user interface. (Perhaps 
> "renames" should have a "service check" at the same time? I don't know.)

We have actually discussed this very point. I can give you the
differences (rename will only change a name, it won't move a file to a
new directory, move will only move to a new directory, it won't change
the name, and mv will do either depending on what seems to make sense).

I do think we are switching to just having the 'mv' command.

> 
> Wiki/website: there is a lot of usefull information there, but it feels 
> somewhat unorganized. I would e.g. at some stage suggest to integrate 
> BzrRevisionSpec into the tutorial (which is now in the tree, I know) such 
> that it by time will grow into a real manual. Also, some more detailed 
> information on the internals of how bzr works (revids, inventory, hashes, 
> etc.) will be nice: again a lot of information seem to be available in the 
> doc/ directory, but it is not clearly organized and it is not clear what is 
> ideas and what has been implemented.

Thank you for pointing out some documentation deficiencies. James, since
you seem to be are documentation guru, can you at least mark some places
where this information should be fleshed out?

> 
> The kind of detailed information that could be usefull in the 
> tutorial/manual could e.g. be how to get the individual changesets that 
> have been merged into a branch as mentioned in the "Disposable branches" 
> thread on the mailing list just before Christmas. I do unfortunately not 
> have enough knowledge of bzr yet to realize these things without detailed 
> information written out... (Hopefully I will get it at some stage!)

Some of this hasn't been fully worked out either :)
It does depend on what you mean by 'get the individual changesets'.
Right now, not all of the code paths support it, but in the future, you
would probably be able to do:

bzr diff -r revid:AAAA..revid:BBBBB
For any revision id which exists. Which means that they can be merged
revisions, etc.

> 
> All in all I am quite impressed by your work, and will definitely follow it 
> in the future as well :-) Keep up the good work!
> 
> Best regards,
> Jens

I'm happy you found it useful. If you do stay with us, don't forget your
recommendations. A lot of things are going on here, and sometimes
suggestions can be forgotten. It doesn't hurt to remind us periodically. :)

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060113/9193d0cb/attachment.pgp