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

[John Arbash Meinel]

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

Aaron Bentley wrote:
> Kent Gibson wrote:
>>> 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.
> 
> Personally, I'd like to see the merge commits in the long form, but
> others may have different ideas.
> 
>>> 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's expected.  I think we want to support showing changes to
> directory children in the future, but we may wait for a new inventory
> format that would actually mark directories as changed every time one
> their files or directories changed.  (Directory changes would bubble up
> to the root.)
> 
>>>>> 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.
> 
> There may be a way of combining approaches, so that we get almost the
> same speed as this approach, but with greater accuracy.  But if you ever
> wondered why we hadn't fixed this bug before, this is why.  Doing it
> right is a bit messy.

Well neither the .kndx files nor file_ids_altered_by_revision_ids will
report the revisions that deleted a file.

Because our current "commit" code deals in snapshots rather than deltas.
So it doesn't see anything (because that entry just "isn't there"). So
it doesn't know to mark the file's .kndx entry. And our delta code only
includes new lines (it marks deleted lines by their range, but not their
content).

So the only way to get it 100% correct is to actually delta the inventories.

I have taken the position for a while, that commit should create *both*
a snapshot and a delta. There is some potential for redundancy, and
possible disagreement (because you are recording the same data twice,
there always *could* be disagreement).

But far too often we want the "delta" and all we have is 2 fulls that we
need to diff. (For example, bzr log --verbose could quickly dump the
stored (and accurate) deltas. bzr diff -r X-1..X could compute it
without needing to extract full texts, and
file_ids_altered_by_revision_ids wouldn't have to be such a gross hack)

> 
>>> 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.
> 
> Individual file knits are required to have revisions for all the
> revisions referred to in the inventory knit, but they are permitted to
> have more.
> 
> Aaron

I wonder (though I doubt) that this would contain any unmerged branches.
I'm doubting it because when you do a new branch of the data, it should
ignore all of them.

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

iD8DBQFF/BchJdeBCYSNAAMRAtZ5AKC82q43sB2K+unbHHKEFgxLmnKAcwCeI2H+
Nb14kiPEcLnV7lbc90Ttwck=
=xnak
-----END PGP SIGNATURE-----