Re: Can anyone correct the Bazaar reference "revno:111954.1.97"?

[Eli Zaretskii <eliz@gnu.org>]

> From: Joshua Judson Rosen <rozzin@geekspace.com>
> Cc: esr@thyrsus.com,  handa@gnu.org,  emacs-devel@gnu.org
> Date: Sun, 02 Mar 2014 00:53:00 -0500
> 
> > > > >     revno: 111954.1.4
> > > > >     committer: K. Handa <handa@gnu.org>
> > > > >     branch nick: work
> > > > >     timestamp: Fri 2013-03-22 00:18:44 +0900
> > > > >     message:
> > > > >       Fix a bug introduced by revno:111954.1.97
> > > > > 
> > > > > It doesn't show up in a bzr log --levels=0 listing, and the fact that
> > > > > 97 > 4 suggests the reference is garbled.
> > > >
> > > > I think the correct reference is 111964.1.6.  It was merged in
> > > > r112051.
> > > 
> > > ... and the "revno:111954.1.97" was a reference to trunk revno:112051.
> >
> > No, it isn't, IMO: they have different parents.
> 
> They actually don't have different parents--they have the same revid,
> and really _are_ the same revision-object.

No, they haven't, and no, they aren't:

  ------------------------------------------------------------
  revno: 111964.1.6
  revision-id: handa@gnu.org-20130315160354-jkntpv64yp0n0iql
  parent: handa@gnu.org-20130311090639-hslbvd6ot0k25lsn
  committer: K. Handa <handa@gnu.org>
  branch nick: work
  timestamp: Fri 2013-03-15 16:03:54 +0000
  message:
    Optimize ASCII file reading with EOL format detection and decoding.

  ------------------------------------------------------------
  revno: 111964.1.7 [merge]
  revision-id: handa@gnu.org-20130315160447-x6zr5fjm1ez02upn
  parent: handa@gnu.org-20130315160354-jkntpv64yp0n0iql
  parent: michael.albinus@gmx.de-20130315141906-e85ws6zvzcq6wk75
  committer: K. Handa <handa@gnu.org>
  branch nick: work
  timestamp: Fri 2013-03-15 16:04:47 +0000
  message:
    merge trunk
  ------------------------------------------------------------

  revno: 112051 [merge]
  revision-id: handa@gnu.org-20130315160612-scmr21as4wy0g99w
  parent: michael.albinus@gmx.de-20130315141906-e85ws6zvzcq6wk75
  parent: handa@gnu.org-20130315160447-x6zr5fjm1ez02upn
  committer: K. Handa <handa@gnu.org>
  branch nick: trunk
  timestamp: Fri 2013-03-15 16:06:12 +0000
  message:
    Optimize ASCII file reading with EOL format detection and decoding.
  ------------------------------------------------------------

Bazaar is deeply branch-centric, and distinguishes between a "regular"
commit and its merge-commit.

> On Eric's spectrum between "philosophical" and "serious can of worms",
> I'd say the severity of picking the wrong one of these two revisions
> to associate with "the bug" in Handa's later commit-comment is
> a lot closer to "philosophical" than to "serious can of worms"...,
> but you can verify that Handa's "revno:111954.1.97" must have
> referred to trunk revno 112051:

I really don't see a problem, since, as can be seen from the above,
the time stamps of each of these 3 revisions are different.

> > Unless you are saying that Handa-san used two different branches that
> > both forked at trunk r111954
> 
> Well, yes: it looks like Handa was using both "trunk" and a separate
> "work" branch, and merging back and forth between the two.

No, I meant 2 branches _in_addition_ to the trunk.

> Handa wrote "Fix bug introduced by revno:111954.1.97" into a commit
> at "work 111958".
> 
> The same "do something in `work' and the merge trunk into `work'"
> cycle was repeated a couple more times on "work", up to "work 111961".
> 
> Then "work" was merged back into trunk at trunk revno 112229
> (where "work 111957" became "trunk 111954.1.3", "work 111958"
> became "trunk 111954.1.4", etc.).
> 
> If you separate that "work" branch back out of trunk so that you can
> look at the log "from work's perspective", then all of the numbers match
> up with how Handa would have seen them when he wrote the comment that
> tripped Eric up; you can go look the commit-objects up, get their
> revids, and verify that "work 111954.1.97" is the same object as
> "trunk 112051".

No matter what was done with the "work" branch, the count of its
revisions is strictly increasing, and so .1.97 cannot possible precede
.1.4.

> > I don't see how .1.97 can come before .1.4 on the same branch.
> 
> Of course--they weren't on the same branch.

Then there must be a third branch, in addition to trunk and "work",
and that 3rd branch must have been forked from trunk at the same
revision 111954.  That's what I said.

> This is why I say that, when Handa wrote "111954.1.97" in his "work" branch,
> the revision that he was referencing was in fact "trunk 112051".

Can't happen with just 2 branches, AFAIU.

> Same node in the DAG, addressed differently by observers sitting at
> different points in the DAG.

As I show above, they aren't the same nodes in the DAG.