Comment 3 for bug 318993

On Tue, 2009-01-20 at 15:22 +0000, Wesley J. Landaker wrote:
> Sorry to lump multiple issues together.
>
> I filed the --depth wishlist issue as #319256.
Thanks!

> 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.
It can skip the "fetching revision info" step if you disable bzr-svn's
internal caches (use-cache=False in ~/.bazaar/subversion.conf).

It still has to analyse *some* revisions to guess the repository layout,
even for "bzr info", to determine whether the path you have specified is
a branch or not.

> 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).
As I mentioned earlier, bzr's API (including bzr's working tree
operations) are based around file ids. In order for bzr-svn to come up
with these file ids (that svn doesn't have), it needs to generate them
by analysing history. The only way to fix this would be to significantly
change how Bazaar worked internally, and I don't think this is very
likely.

> 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).
using bzr formats rather than svn formats locally should be a lot
faster.

The file ids should only be generated once, after that they should be
retrieved from the cache. If you're seeing the analysing history bit
more than once for a single branch, that is definitely a bug.

> P.S. I'm happy to now be reporting mostly wishlist bugs, since that
> means I'm having a hard time breaking bzr-svn. ;)
:-) That's good to hear.
--
Jelmer Vernooij <email address hidden> - http://samba.org/~jelmer/
Jabber: <email address hidden>