[MERGE] Fix #175520 by implementing a --deep option for log

[Ian Clatworthy]

Vincent Ladeuil wrote:
>>>>>> "Ian" == Ian Clatworthy <ian.clatworthy at internode.on.net> writes:

>     Ian> I can agree to that. Part of my point though was that
>     Ian> your patch isn't finding old file-ids and using them:
>     Ian> it's matching on names (which is great) but then doesn't
>     Ian> use the file-ids found.
> 
>     Ian> Practically, it probably doesn't matter in 99% of cases
>     Ian> *but* bzr is unique partly because we (claim to) handle
>     Ian> renames correctly, so that implies we ought to use the
>     Ian> file-id once we know it IMO.
> 
> File ids used in the working tree can be found via dirstate. No
> longer used file ids have to be searched in the
> inventories. Since we have to search all inventories, there is no
> place to reuse the file id once it's discovered.

Alternatively, once you have found a file-id, you can search by it
instead of name. If the file-id doesn't exist in a inventory,
start searching by name again. You probably need to watch the
edge case where the file-id was added - a file of the same name
but different file-id may have been deleted in the same revision?
In theory, that's a "rename" but we arguably should report what
we recorded.

Hmm, I can see the problem with the above: you can miss
references to a file X because the most recent X was once
called Y at the same time. Again, not very likely in practice
but possible. Fast and correct just aren't going to play
together on this task it seems ...

It makes me wonder whether we ought to explicitly make old
file logging a 2 step operation:

  $bzr log --find-file-ids FILE
  Create/renames/deletes for FILE: (use log --file-id for more information)
  file-id AAA:
    deleted in Z
    added in Y
  file-id BBB:
    deleted in X
    renamed in W from FILE to FILE.txt
    added in X
  $bzr log --file-id AAA
  ...

The second step should be as fast as normal per-file logging,
while the first step can be slow provided we progressively show
output, letting the user abort as soon as they like, e.g. after
the first operation on the first file-id found searching backwards
is reported. I don't think we should show modifications to a file
by default here - just the "lifecycle" operations. OTOH, if they
specify "log -v --find-file-ids FILE", including the modifications
would be reasonable.

I'd be happy even if we didn't try for "perfect" output
(like above) for --old. For example, the "deleted in X" line
looks very expensive to work out. This would do ...

  $bzr log --find-file-ids FILE
  Create/renames/deletes for FILE: (use log --file-id for more information)
  file-id AAA:
    delete detected in Z
    add detected in Y
  file-id BBB:
    rename detected in W (FILE => FILE.txt)
    add detected in X


> Of course, I was referring to the fact that if you show the log
> for a single dotted revno, you have no way to find the mainline
> revision is it merged into. That's why bzr log FILE shows those
> revisions. And it address a very common need: most of the time I
> don't really care what precise revision introduced a change, I'm
> more interested in knowing when that change landed, so I want the
> mainline revision.

Me too.


>     >> >> +    def test_log_old_file_deep(self):
>     >> >> +        log = self.run_bzr(['log', '-v', '--short', '--deep', 'f1'])[0]
>     >> >> +        # revnos 1 and 2 appear and mention adding and deleting f1
>     >> >> +        self.assertContainsRe(log, '(?sm)^ +2 joe.*D  f1\n.*^ +1 joe.*A  f1\n')
>     >> >> +        self.assertNotContainsRe(log, '(?sm)^ +3 joe')
>     >> 
>     Ian> Hmmm, this is testing exactly the same parameters as
>     Ian> "test_log_file_deep_short".
>     >> 
>     >> Same parameters but a different file (f1 instead of f2) with a
>     >> different history.
> 
>     Ian> I got that. :-) At a minimum, I'd put the two tests next to each
>     Ian> other
> 
> ok.
> 
>     Ian> (or combine them even).
> 
> Urgh :-) Defect localization ftw !

I was expecting you to say that. :-) Just be sure the 2 test
names reflect their commonality and differences please, unlike now.

Ian C.