Re: broken bzr history?

[Óscar Fuentes]

Glenn Morris <address@hidden> writes:

> The following is from http://debbugs.gnu.org/5652#8 and onwards.
> It sounds potentially serious. Is it?
>
> Juri Linkov wrote:
>
>>>> I typed `C-x v g' (vc-annotate) in info.el, and it displays:
>>>>
>>>>   49780.1.32 henrik. | (forward-line (1- (nth 3 (car 
>>>> Info-index-alternatives))))
>>>
>>> Looks like a bug in bzr.  With git blame it points to f4ed1f85:
>>>
>>> commit f4ed1f852b3fb7650178446ac53db773d9fd25d6
>>> Author: Juri Linkov <address@hidden>
>>> Date:   Tue Apr 27 06:39:46 2004 +0000
>>
>> Yes, I can confirm this is the correct commit.  In read-only CVS I see:
>>
>> revision 1.393
>> date: 2004-04-27 09:39:46 +0300;  author: jurta;  state: Exp;  lines: +80 
>> -42;
>> [...]
>> (Info-index-next): Decrement line number.

I don't think that the branch is corrupted.

What is now known as bzr revision number 49780 was the point where the
rmail-mbox branch was created on CVS. That branch synched at least once
with mainline. At certain point, the branch was merged into
mainline. Much later, Emacs migrated to bzr. And after that, on revision
99255, a fake merge was created for "injecting" the rmail-mbox branch
into the bzr history. My hypothesis is that all history that was merged
from mainline into rmail-mbox during its lifespan now is shown by
`annotate' as coming from that branch. Try

bzr log -n0 -r 99255 | less

you will see the fake merge and, scrolling down, that 49780.1.32 is
commented as "sync with trunk".

git uses a different heuristics for `annotate' and displays the right
thing (this is a case where git's "we track content, not files" shows
its strength.)

IIRC, revision 99255 was famous because it forced bzr clients to
download about 100 MB while updating the local mirrors.

Stefan, how did you create that merge revision?