[RFC] Change to use 'merge_sort' for per-file-log

[John Arbash Meinel]

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

Robert Collins wrote:
> sorry to revert my position on you, I think I need to understand this
> more....
> 
> On Thu, 2008-09-18 at 22:49 -0500, John Arbash Meinel wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> The attached patch overrides my previous work, by changing how we determine
>> what revisions to display. This is RFC because of the behavior change. Though
>> I think most will probably *prefer* this behavior.
>>
>> So, what is the behavior change. The new code shows merges *towards mainline*
>> that include the a new change to the file, but ignore merges away. So for example:
>>
>> A-.    # A creates 'foo'
>> |\ \
>> B C D  # C modifies 'foo'
>> |/  |
>> E   |  # Pulls in 'foo' verbatim from C
>> |\  |
>> | \ |
>> |  \|
>> |   F  # Pulls in 'foo' verbatim from E
>> |  /
>> | /
>> |/
>> G
>>
>> The old algorithm would show A, C, E, and F, the new algorithm will not show F.
> 
> If D did not modify 'foo', then the per file graph for 'foo' will not
> include a node "D" OR a node 'F'.
> 
> In fact, it will be:
> "C":["A"]
> "A":[]
> 
> So log should be showing A and C only. I think something is confused in
> your sample data, or in your explanation.

You are completely correct about the *per file graph*, you are incorrect
about "bzr log".

The reason goes back to long ago when we used "delta" to determine
whether to include a file in 'bzr log file'. In that case, both 'E' and
'F' have a delta versus their left-hand parent for the file 'foo'.

When someone changed 'bzr log file' to *only* use the per-file graph,
Aaron noticed, and commented that he really liked seeing nodes like 'E'
in the output. Because it made it obvious when that change was merged
into trunk, etc.

I believe it was Kent Gibson who proposed the original update (back in
bzr-0.16 according to NEWS).

So the 'bzr log file' algorithm changed, so that we compute the ancestry
of the file_id at every revision. And if the left-hand ancestry is not a
superset of the right-hand ancestry, we included the node. (Which should
be equivalent to doing inventory deltas against the left-hand parent
along the way.)

I fixed the original implementation to not create a new set for every
revision (but still created a new set at every merge point). The first
patch in this series changed it to create a new set only when needed.

Now, I have a plugin that does what you are saying:
lp:~jameinel/+junk/bzr-file-log. Doing "bzr file-log foo" will only show
A and C.

bzr 1.7 will show A, C, E, F
bzr 1.8 (if this change is merged) will show A, C, E.

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

iEYEARECAAYFAkjXtPkACgkQJdeBCYSNAANpRACfTAX7/3IHu4r31EqUp71l6YIB
BoYAn1v6xgKcc76mmUMxW4mlZymW/r8C
=RNkf
-----END PGP SIGNATURE-----