[RFC] proposed changes to log UI

[John Arbash Meinel]

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



...

> I'm putting together a patch along these lines now. The core code
> changes are simple bar the test tweaks/enhancements. The main
> blocker is that "log --short FILE" doesn't work correctly
> currently. To be investigated ...
> 
> Ian C.
> 

"bzr log --short FILE" will show you all of the mainline revisions that
modified FILE (directly, not as a merge).

That is (IIRC) because we take the intersection of "revision_ids to log"
 against the "revision_ids in the per-file graph".

To "work" the way I think you are thinking, you have to change the code
to still generate the "merge_sort" listing, and intersect the file_id
revision graph with the whole revision graph, and then propagate the
per-file revisions to the mainline, and then filter out only the
mainline revisions.

It is a bit clumsy because we don't have "child" pointers in our
ancestry graphs. So there is no way to go from a per-file graph into the
"merged into" revision graph, without loading most of the revision
graph. In theory you could start collecting the full ancestry until you
ran into these nodes, but there are other complications dealing with
whether this is the 'first' ancestry path. For example:

  :
  A
  |\
  B C
  | |\
  D E |
  |/ /
  F G
  | |
  H |
  |/
  I

In this case, if you are looking for 'C' it should be displayed as part
of merged-into F, and not as "merged-into I". Though if you walk the
graph, you'll see that C is an ancestor of I before you see it as an
ancestor of F.

So to compute the 'merge_sort' graph, you need to walk backwards from C
until you find it descends from A, and then walk all of the ancestors
for B-I until you converge before A, to ensure that you have the
earliest revision that merged C. (Note this gets really bad when B
merges something descended from a revision before A, because you have to
keep walking until you get to something that shows you it cannot include
C. Namely you run into something you know is an ancestor of A.)

That is why my 'lazy_revno' branch has a hard time just evaluating a
small region of the revision graph. If you use bzr qlog, you can see
that all of our revisions play "leap-frog", and we often have a very
small branch leap over branches with huge ancestries (so it takes a long
time to iterate enough ancestry to determine that we really are done).

One option is adding the Greatest Distance From Origin cache. Which
gives you an idea if one revision could descend from another. (If
GDFO(a) < GDFO(b) then a cannot descend from b.)

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

iEYEARECAAYFAklubEgACgkQJdeBCYSNAAN5eACgmotKTtnJGO3T6tC567txynV7
hKoAnjDOYyLFOhai7PI6oM0VFB1mQ+Rh
=HSke
-----END PGP SIGNATURE-----