builtin annotate near useless

[Wouter van Heyst]

While the help text for annotate claims it prints the originating revision, annotate doesn't actually do this.

This makes it very hard to traverse history, though annotate takes an -r parameter, you will have to find what revision to give with another tool.

[John A Meinel (jameinel)]

I'm not sure what you mean.
It does show the revision number for the original revisions if it is a mainline revision.
Because our bzr.dev workflow has switched to using pqm, almost all of them show 'merge' at this point.

So there are 2 fixes:

1) Show the dotted revision number rather than just 'merge'.
2) Have a flag to show the exact revision id, though that necessarily takes up a lot of space.

If we do that, we may want it to not show the full user id, since we probably can just get that from the revision id.

Certainly it isn't as useful as gannotate. But I'm not sure that 'useless' is accurate.

Otherwise I'm not sure what you mean by 'traverse history.'

[Wouter van Heyst (larstiq)]

I had been using a combination of annotate, gannotate and webserve to track things down in bzr.dev. I see with `bzr annotate build-api` it does indeed list mainline revisions, but on actual bzr.dev that very rarely happens. So I should have said, 'near useless for bzr.dev' (or other branches that heavily merge).

The way I prefer to use (gannotate) is that I begin with annotating a file (at a particular revision) and look at when the line of interest last changed. Usually, the introduction of certain behaviour was made before that, so I have to annotate that file again, but this time at the revision the line last changed at, etc.

When annotate does not give me that information, there is no drilling I can do, and with bzr.dev, this amounts to almost all relevant changes I'd want to look at.

[Aaron Bentley (abentley)]

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

Wouter van Heyst wrote:
> Public bug reported:
>
> While the help text for annotate claims it prints the originating
> revision, annotate doesn't actually do this.

It does print the originating revision, but only if it has a non-dotted
revno. Non-lefthand ancestors get "merge" instead.

Henri Wiechers proposed to print the revno of the merging revision in
such cases:
http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/19535/focus=19535

I suggested the dotted revno might be nicer, and gave some advice on
implementing both approaches, but Henri hasn't posted since Nov 22.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFFgE0q0F+nu1YWqI0RAkl0AJ4u0F1197kfjeQCMOYs5Ff6jGJr0gCeODZL
CJpE87GuasEVyiV0hQHzcR8=
=x8qG
-----END PGP SIGNATURE-----

[Goffredo Baroncelli (kreijack)]

I think that it is better to show the dotted revno instead the "merge" string.
But pay attention that the dotted revno can be __very__long, ( see revision <email address hidden> which has ,in the official bzr.dev, revno = 1551.2.49.1.40.1.22.1.42.1.10;
http://goffredo-baroncelli.homelinux.net/bazaar-dev/bazaar-NG-dev?cmd=revision;revid=aaron.bentley%40utoronto.ca-20061207040634-4j6dz1bpkqcue0tb )

[John A Meinel (jameinel)]

I actually implemented dotted revno just now. And it turns out that one is a small one. Andrew Bennetts has one with:
1910.3.1.1.2.2.17.2.1.1.1.1.1.1.1.1.4.1.2.1.1.2.10

So my implementation defaults to truncating them at 12 characters and putting:
1910.3.1.1.>

Which looks pretty good.

I'm also working on adding --show-ids, which will just use the revision ids themselves. And then I need to add some test cases, etc.

[Wouter van Heyst (larstiq)]

On Wed, Dec 13, 2006 at 06:57:46PM -0000, Aaron Bentley wrote:
> Wouter van Heyst wrote:
> > Public bug reported:
> >
> > While the help text for annotate claims it prints the originating
> > revision, annotate doesn't actually do this.
>
> It does print the originating revision, but only if it has a non-dotted
> revno. Non-lefthand ancestors get "merge" instead.
>
> Henri Wiechers proposed to print the revno of the merging revision i.
> such cases:
> http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/19535/focus=19535
>
> I suggested the dotted revno might be nicer, and gave some advice on
> implementing both approaches, but Henri hasn't posted since Nov 22.

John mentioned that on irc, and also did some work on
http://bzr.arbash-meinel.com/branches/bzr/0.14-working/annotate_show_ids/
which makes working with annotate on bzr.dev nice again.

Wouter van Heyst

[Aaron Bentley (abentley)]

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

John A Meinel wrote:
> I actually implemented dotted revno just now. And it turns out that one is a small one. Andrew Bennetts has one with:
> 1910.3.1.1.2.2.17.2.1.1.1.1.1.1.1.1.4.1.2.1.1.2.10
>
> So my implementation defaults to truncating them at 12 characters and putting:
> 1910.3.1.1.>
>
> Which looks pretty good.
>
> I'm also working on adding --show-ids, which will just use the revision
> ids themselves. And then I need to add some test cases, etc.

Perhaps I'm spoiled by gannotate, but I think it's much nicer to show
the full information about the associated revision while it's selected.
 Maybe a curses version...

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFFgGlk0F+nu1YWqI0RAmkxAJ9f0QlApj03Rvzs6SvaWzwRoCiHgACePpiN
7rt3t27IAaEDVOBn6pAHVGQ=
=+hTy
-----END PGP SIGNATURE-----

[John A Meinel (jameinel)]

The associated branch has been merged