bzr log -v -n 0 takes too long to get started; needs lazy revnos

Trond Norbye wrote:
> Public bug reported:
>
> After I have pulled source into my repository I normally want to see the
> new changes I got into my repository, and I normally do this with bzr
> log -v -n 0 | less. This takes unfortunately ~ 3-4 seconds before
> displaying anything on my terminal, making the command feel really
> sluggish...

Is the -n0 important to you? If you're happy with just 'log -v -l 10',
the output should be instantaneous.

Ian C.

To elaborate a bit on Ian suggestion: '-n 0' (also called --include-merges) requires that we calculate the revnos.
This currently requires that we load the whole ancestry graph (not exactly, not everytime, but close enough that
 it makes no difference).

So until we rework the revno calculation to be lazy (which is planned) we won't make good progress here.

I need -n 0 to see the commit messages. Just using -l 10 only includes the commit message for the merge, and that is typically: "Merge name"... and that doesn't tell me much about what the content of the merge is..

If there is a way I can see all of the commit messages without -n 0 I'll be happy to use it.. the things I want to see is:

Revision number
Comitter (for pushing the changeset, I don't care that much for the individual changesets in the merge, I can drill down to that later on if I find a problem)
Date for the commit
All of the commit messages in the merge / commit
All of the files included in this merge (I don't care that much about the separation of added/modified/deleted etc)

You want the 'Revision number'. The problem is in calculating the dotted revnos (213.4.14).
Unless we rework that, no joy.
I'm not even sure you can work around that by writing your own log formatter...

Which is weird, I thought we had the ability to display log *without* revnos but I can't find it back.

So, trying to backtrack a bit, what *I* use is:

    bzr pull -v

instead of your:

    bzr pull
    bzr log | less

You'll get the ouput sooner with the former but you'll miss the delta (-v has a different meaning there).

Do you have to calulate the revision numbers for each revision in the change log?? I don't need the revision numbers for the changes inside the merge, only the revision number for the merge itself. With this revision number I can run a separate bzr command if I want to drill down into that merge....

bzr pull -v is nice, but it doesn't contain the files included in each of the changesets (but thanks for the tip, I'm definitively going to start using this command!).

I still want to be able to run another command to get the info I want, because I also use that during development (to figure out why someone did something etc)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Trond Norbye wrote:
> Do you have to calulate the revision numbers for each revision in the
> change log?? I don't need the revision numbers for the changes inside
> the merge, only the revision number for the merge itself. With this
> revision number I can run a separate bzr command if I want to drill down
> into that merge....
>
> bzr pull -v is nice, but it doesn't contain the files included in each
> of the changesets (but thanks for the tip, I'm definitively going to
> start using this command!).
>
> I still want to be able to run another command to get the info I want,
> because I also use that during development (to figure out why someone
> did something etc)
>

Note that this should be moderately better in the 2.0 release. I landed
a patch which changes the time to compute dotted revnos substantially on
most projects. (bzr.dev goes from 2.5s => 1.0s for me, OOo goes from
30+s => ~10s.) It isn't a perfect fix (still computes everything), but
it does seem to be significantly better.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqdKxEACgkQJdeBCYSNAAN1ZACg2S6TAMRaW7dBQu8GI8qDNmrR
7ZUAn2xpkk/LFqRBA8bT+CC7ybcKzfZF
=zvZv
-----END PGP SIGNATURE-----