broken bzr history?

broken bzr history?

[Glenn Morris]

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 <juri@jurta.org>
>> 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.

Re: broken bzr history?

[Óscar Fuentes]

Glenn Morris <rgm@gnu.org> 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 <juri@jurta.org>
>>> 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?

Re: broken bzr history?

[Stefan Monnier]

> Stefan, how did you create that merge revision?

IIRC it was something like:

  bzr merge <branch>
  [... inspect bzr diff to make sure there's nothing left unmerged ...]
  bzr revert .
  bzr commit -m <msg>

In any case, it was a stupid idea on my part, and I'm "glad" to see that
I'll get to regret it some more in the future.


        Stefan

Re: broken bzr history?

[Óscar Fuentes]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Stefan, how did you create that merge revision?
>
> IIRC it was something like:
>
>   bzr merge <branch>
>   [... inspect bzr diff to make sure there's nothing left unmerged ...]
>   bzr revert .
>   bzr commit -m <msg>
>
> In any case, it was a stupid idea on my part, and I'm "glad" to see that
> I'll get to regret it some more in the future.

Well, that method was what I used while migrating some svn repos to bzr,
after the bzr developers sanctioned it. I guess that they are not aware
of the effects on `annotate'.