bzr log -rA..B returns more revisions than expected

Bug #325618 reported by Kent Gibson on 2009-02-05
0
Affects Status Importance Assigned to Milestone
Bazaar
Undecided
Marius Kruger

Bug Description

A recent change (between bzr 1.11 and r3980) has broken the range limits on bzr log.
For example using bzr 1.11:

$ bzr log -r3955.2.1..3967
------------------------------------------------------------
revno: 3967
committer: Canonical.com Patch Queue Manager <email address hidden>
branch nick: +trunk
timestamp: Wed 2009-01-28 17:40:48 +0000
message:
  (vila, jam) Make merge_content lca aware
    ------------------------------------------------------------
    revno: 3966.1.1
    committer: Vincent Ladeuil <email address hidden>
    branch nick: bzr.integration
    timestamp: Wed 2009-01-28 15:27:39 +0100
    message:
      Make merge_content lca aware
    ------------------------------------------------------------
    revno: 3948.1.7
    committer: Vincent Ladeuil <email address hidden>
    branch nick: spurious-conflicts
    timestamp: Fri 2009-01-23 22:06:48 +0100
    message:
      Slight refactoring and test fixing.

      * bzrlib/tests/test_merge.py:
      (TestMergerEntriesLCAOnDisk.test_modified_symlink): Passing now.

      * bzrlib/merge.py:
      (Merge3Merger._lca_multi_way): Fix doc reference.
      (Merge3Merger.merge_contents.contents_conflict): Try to delay
      this_pair evaulation to avoid unnecessary sha1 (impyling file read
      from disk) calculation. Also slightly refactor to avoid repeated
      file_id in trees calculations.
    ------------------------------------------------------------
    revno: 3948.1.6
    committer: Vincent Ladeuil <email address hidden>
    branch nick: spurious-conflicts
    timestamp: Fri 2009-01-23 20:45:02 +0100
    message:
      Remerge jam fix and its ancestry
        ------------------------------------------------------------
        revno: 3955.2.1
        committer: John Arbash Meinel <email address hidden>
        branch nick: jam-integration
        timestamp: Fri 2009-01-23 10:54:53 -0600
        message:
          Change the workings of merge_content to be lca aware.

but for bzr.dev r3980 returns:

$ bzr log -r3955.2.1..3967
------------------------------------------------------------
revno: 3967
committer: Canonical.com Patch Queue Manager <email address hidden>
branch nick: +trunk
timestamp: Wed 2009-01-28 17:40:48 +0000
message:
  (vila, jam) Make merge_content lca aware
    ------------------------------------------------------------
    revno: 3966.1.1
    committer: Vincent Ladeuil <email address hidden>
    branch nick: bzr.integration
    timestamp: Wed 2009-01-28 15:27:39 +0100
    message:
      Make merge_content lca aware
    ------------------------------------------------------------
    revno: 3948.1.7
    committer: Vincent Ladeuil <email address hidden>
    branch nick: spurious-conflicts
    timestamp: Fri 2009-01-23 22:06:48 +0100
    message:
      Slight refactoring and test fixing.

      * bzrlib/tests/test_merge.py:
      (TestMergerEntriesLCAOnDisk.test_modified_symlink): Passing now.

      * bzrlib/merge.py:
      (Merge3Merger._lca_multi_way): Fix doc reference.
      (Merge3Merger.merge_contents.contents_conflict): Try to delay
      this_pair evaulation to avoid unnecessary sha1 (impyling file read
      from disk) calculation. Also slightly refactor to avoid repeated
      file_id in trees calculations.
    ------------------------------------------------------------
    revno: 3948.1.6
    committer: Vincent Ladeuil <email address hidden>
    branch nick: spurious-conflicts
    timestamp: Fri 2009-01-23 20:45:02 +0100
    message:
      Remerge jam fix and its ancestry
        ------------------------------------------------------------
        revno: 3955.2.1
        committer: John Arbash Meinel <email address hidden>
        branch nick: jam-integration
        timestamp: Fri 2009-01-23 10:54:53 -0600
        message:
          Change the workings of merge_content to be lca aware.
    ------------------------------------------------------------
    revno: 3948.1.5
    committer: Vincent Ladeuil <email address hidden>
    branch nick: spurious-conflicts
    timestamp: Fri 2009-01-23 20:40:36 +0100
    message:
      merge jam fix
------------------------------------------------------------
revno: 3966
committer: Canonical.com Patch Queue Manager <email address hidden>
branch nick: +trunk
timestamp: Wed 2009-01-28 10:54:51 +0000
message:
  (Jelmer) Move ForeignVcsMapping.show_foreign_revid to ForeignVcs.
    ------------------------------------------------------------

<snip/>

    ------------------------------------------------------------
    revno: 3948.2.3
    committer: Martin Pool <email address hidden>
    branch nick: progress
    timestamp: Wed 2009-01-21 03:38:16 -0200
    message:
      Make the interface from ProgressTask to ui more private
    ------------------------------------------------------------
    revno: 3948.2.2
    committer: Martin Pool <email address hidden>
    branch nick: progress
    timestamp: Wed 2009-01-21 03:30:44 -0200
    message:
      Corrections to finishing progress bars
    ------------------------------------------------------------
    revno: 3948.2.1
    committer: Martin Pool <email address hidden>
    branch nick: progress
    timestamp: Wed 2009-01-21 03:01:32 -0200
    message:
      Add ProgressTask repr

i.e. it has returned the log I would expect from "bzr log -r3948.2.1..3967", not "bzr log -r3955.2.1..3967".
The problem only seems to be present when one of the revisions is a merge revision.
Looking at the revision history in bzr visualize, I note that 3948.2.1 is the first revision after the thread containing 3955.2.1 branched from the mainline at 3955.

Related branches

Marius Kruger (amanica) on 2009-05-08
Changed in bzr:
assignee: nobody → Marius Kruger (amanica)
Marius Kruger (amanica) wrote :

After spending a lot of time debugging this, I'm not 100% sure we want to fix this any more.
If I understand correctly, the behaviour you see is because when we show the log of the specified revisions, we show everything up to just before we hit the mainline (the left parent).
So if we want to fix this, we need to stop logging revisions once we hit the 'last revision' which could be implicitly specified by example `bzr log -n0 -r-2` which would currently display something like:
revno: 4510 [merge]
    revno: 4509.1.1
If we stop logging at rev -2 which is 4510,
`bzr log -n0 -r-2` would now only show:
revno: 4510 [merge]
and if you would like to see 4509.1.1, you would need to do so something like:
`bzr log -n0 -r-3..-2`
revno: 4510 [merge]
    revno: 4509.1.1
revno: 4509 [merge]
or `bzr log -n0 -r4509.1.1..-2`
revno: 4510 [merge]
    revno: 4509.1.1

So do we want this?

Changed in bzr:
status: New → In Progress
Changed in bzr:
status: In Progress → Fix Released
milestone: none → 2.1.0b4
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers