[MERGE][BUG] 51980: bzr log <file>returns inappropriate revisions

[Kent Gibson]

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



Aaron Bentley wrote:
> Aaron Bentley wrote:
>> Aaron Bentley has voted -0. Status is now: Waiting Comment: This
>> doesn't look right, because it only shows revisions that
> introduced
>> the change.  It will omit revision_history revisions that merged
>> a change.  Since most log views only show revision_history
> revisions, the
>> change will not be shown at all for them.  So this would change
>> the current output in ways I don't want.
>

Good point - I had only been considering long logs, and not any
changes to the shorter forms.
I know one of the things I'm always trying to find out is when a
particular change was merged into bzr.dev.  I hadn't realised that log
- --short gives you that.  Well almost.
I definitely want a command that provides that info, but I'd also
prefer something more direct than fishing it out of the log.

In my mind at least, ``bzr log <file>`` should only show the revisions
that change the file, and exclude merge commits.  Is it the general
consensus that it should include merge commits?  I'm just talking the
long form here - I agree with you on the short forms.

I'm also curious as to how ``bzr log <directory>`` is expected to behave.
Currently it only shows changes to the directory itself, not the files
contained in the directory tree.  That is in both bzr.dev and my
patch, btw.
I think there are cases for showing both, so perhaps we could use `bzr
log <directory>/`` to mean the latter?
> I *think* the best way to make it fast is to use
> fileids_altered_by_revision_ids.
>

I tried something like that originally.
It was better than the deltas approach, but no where near as fast
Robey's approach - fileids_altered_by_revision_ids is sufficiently
slow that it has a progress bar.
And the output was the same, at least for the examples I checked at
the time.
No merge commits in either.

Worryingly, I just compared the output of the two approaches on NEWS
and the fileids_altered_by_revision_ids approach returned a few
revisions LESS.
Note sure if that means the patch returns incorrect revisions, or
fileids_altered_by_revision_ids is missing some.
More investigation required, but at least one of them is sure to be
wrong, if not both.


Cheers,
Kent.


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

iD8DBQFF+13JgoxTFTi1P8QRAtNAAJwPth050VUdvzYgkMOB3AVzIHaPaACgw+tn
E2mbjiDGxAZvZhPkD565hlI=
=lWZ/
-----END PGP SIGNATURE-----