Bazaar Subversion Plugin

Bug #318993
Comment #2

Comment 2 for bug 318993

Revision history for this message

Wesley J. Landaker (wjl) wrote on 2009-01-20:

Sorry to lump multiple issues together.

I filed the --depth wishlist issue as #319256.

If there is something else that should be a separate bug that you see, please point it out, but I think the other issues mostly boil down to doing extra work when it (seemingly) is unnecessary. As I said, it may actually be necessary in practice because of the bzr-svn architecture.

bzr info is a good example:

If I do bzr info -v, I can see how it needs to do all the checking, because that gives me info about the format, working tree, branch history, number of revisions, etc. However, if I just do bzr info without -v, all I get is three lines telling me that it is a checkout and pointing at the branch URL, so it seems like this shouldn't need to do all the extra enumeration since it's not going to print any of it out.

I think bzr status, diff, added, etc, etc, are all similar: they just work on the working tree, so shouldn't need any large amount of history, but they print out a progress bar saying that it's analyzing repository layout and then determining changes for every revision. For example, this seems unnecessary for status and diff (without -r arguments or anything funny like that), since they are only concerned with differences between the working tree and the last revision. Mostly, it's a matter of I'm expecting to do a O(1) operation and instead it's O(revisions).

To give a real example, for a large SVN repository with many thousands of revisions, to just do a status of a single directory takes about 1 second with svn status and almost 10 seconds with bzr status. Almost all of the time is spent with the progress bar going through "analyzing repository layout" and then "determining changes ###/####" for every revision. It's better in repositories with less revisions, and worse in repositories where there are more.

This isn't a horrible slowdown per command, but it adds up in everyday use and makes using bzr in this situation feel really sluggish (I usually just end up reverting to using svn in these cases).

P.S. I'm happy to now be reporting mostly wishlist bugs, since that means I'm having a hard time breaking bzr-svn. ;)

Sorry to lump multiple issues together.

I filed the --depth wishlist issue as #319256.

bzr info is a good example:

I think bzr status, diff,  added, etc, etc, are all similar: they just work on the working tree, so shouldn't need any large amount of history, but they print out a progress bar saying that it's analyzing repository layout and then determining changes for every revision. For example, this seems unnecessary for status and diff (without -r arguments or anything funny like that), since they are only concerned with differences between the working tree and the last revision. Mostly, it's a matter of I'm expecting to do a O(1) operation and instead it's O(revisions).

This isn't a horrible slowdown per command, but it adds up in everyday use and makes using bzr in this situation feel really sluggish (I usually just end up reverting to using svn in these cases).

P.S. I'm happy to now be reporting mostly wishlist bugs, since that means I'm having a hard time breaking bzr-svn. ;)