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

[John Arbash Meinel]

Kent Gibson wrote:
> 
> 
> Kent Gibson wrote:
>>> A |\ B C |/ D
> 
>> - From the little testing I've done the output is a superset of the
>>  output of your full delta patch.  There are a few additional
>> entries because get_weave is reporting a few spurious revisions, as
>>  mentioned in previously in this thread. I'd really like to
>> investigate why get_weave is reporting those spurious revisions to
>> see if they can be stamped out.
> 
> With a little more testing I have found that there are a few more
> revisions being logged than can be accounted for by the get_weave
> weirdness.
> I'm pretty sure this is due to identical changes in two branches being
> merged.
> Specifically, if B and C both make an identical change then the deltas
> approach does not report D, since the content is not changed from
> either B or C.
> But my patch will report D since the ancestry has changed - the
> changes at B and C are identical but get distinct revids, which are
> then merged in D.
> 
> It could be argued that this is even more correct than the deltas
> approach.
> That certainly sounds convincing to me ;-).

I'm happy with that logic. Its why we use the logic for updating the
last-modified-revision.

I haven't had time yet to review your patch, but it sounds (overall)
good. I'll try to make some time to review the code changes. (Thanks for
all your effort, by the way)

> 
> It doesn't seem to happen all that often in real life - the most
> likely case I can think of being when two individuals each merge a
> patch from a third party that requires conflict resolution, and their
> branches are later merged.  It is pretty infrequent, e.g. in NEWS
> there seems to be ~10 such cases out of >2000 revs.
> 
> And one more minor thing while I think of it - is there a reason
> mainline revisions label the revid as "revision-id", while
> non-mainline revisions label them "merged"? e.g.
> 
> revno: 2402
> revision-id: pqm at pqm.ubuntu.com-20070410074302-cf6b95587a1058cd
> parent: pqm at pqm.ubuntu.com-20070405073143-8fa894c829ab5e50
> parent: andrew.bennetts at canonical.com-20070410072043-5vqutcw42bsml4tl
> committer: Canonical.com Patch Queue Manager<pqm at pqm.ubuntu.com>
> branch nick: +trunk
> timestamp: Tue 2007-04-10 08:43:02 +0100
> message:
>   (Andrew Bennetts) Split bzrlib/transport/smart.py into several
> smaller modules
> .
>     ------------------------------------------------------------
>     revno: 2400.1.9
>     merged: andrew.bennetts at canonical.com-20070410072043-5vqutcw42bsml4tl
>     parent: andrew.bennetts at canonical.com-20070410055415-58qifwhu6xfrb5sr
>     committer: Andrew Bennetts <andrew.bennetts at canonical.com>
>     branch nick: split-smart-part-1-rename
>     timestamp: Tue 2007-04-10 17:20:43 +1000
>     message:
>       Fix blackbox/test_serve, there were some trivial changes that
> needed to be
>  brought across from the hpss branch.
> 
> I initially found the "merged" label confusing. Did it mean that rev
> was merged into this one?
> It's not until you use --show-ids and the parents appear that it
> becomes clear(ish).
> And the "revision-id" is only reported with --show-ids, while "merged"
> is always reported.
> Is there some logic to this that I'm missing?
> I thought the display of the two should be the same - excluding the
> indentation of course.
> 
> Cheers,
> Kent.

I think 'merged:' is meant to indicate this revision was merged into the
mainline revision. I would probably say that consistency would be
better, and that the indentation is sufficient to make it clear it is a
merged revision.

I also agree that we should be consistent about when we show revision ids.

I know I'm a little out of the loop for '--long' format, because
honestly I don't ever use it. I use:
bzr log --short -r-10..-1 --forward

as my default. Since it gives me about 1 screenful of just what I care
about (what has been happening recently). And I can use the other when I
need to dig in, but often I use either NEWS or annotate/viz for real
digging.

For example, if I want to know what release a bug was fixed in, NEWS is
the easiest for that.

John
=:->