merge_depth from merge_sorted_revisions incorrect.

[Gary van der Merwe]

I think that the merge_depth field returned from merge_sorted_revisions is incorrect sometimes.

To make it easy to investigate this, I created a branch of qlog that displays the merge depth. The branch is at lp:~qbzr-dev/qbzr/show-merge-depth. I've attached a screen shot of this.

If you look at the following revisions in bzr.dev:
4193
4189.1.1
4183.7.1

The dag and merge depths look like this:
Rev No DAG Merge Depth
4193 * 0
- |\
4189.1.1 | * 1
- | |\
4183.7.1 | | * 1
- | | |
- | | |
- |/ |
- | |
- | /
- |/

Shouldn't the merge depth for 4183.7.1 be 2?

[Gary van der Merwe (garyvdm)]

Grr - my white space got munched. Please see the attached screen shot for a pretty DAG.

Note that this cause bug in other parts of bzr the use the merge_depth. For example, if you run bzr log bzrlib/tag.py, you get:

------------------------------------------------------------
revno: 4193
committer: Canonical.com Patch Queue Manager <email address hidden>
branch nick: +trunk
timestamp: Tue 2009-03-24 05:12:24 +0000
message:
  (mbp) merge update to FSF address
    ------------------------------------------------------------
    revno: 4183.7.1
    committer: Sabin Iacob <email address hidden>
    branch nick: bzr.fsf_addr
    timestamp: Mon 2009-03-23 16:59:43 +0200
    message:
      update FSF mailing address
------------------------------------------------------------
<snip>

4189.1.1 is not there, but it does change bzrlib/tag.py

[John A Meinel (jameinel)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gary van der Merwe wrote:
> Public bug reported:
>
> I think that the merge_depth field returned from merge_sorted_revisions
> is incorrect sometimes.
>
> To make it easy to investigate this, I created a branch of qlog that
> displays the merge depth. The branch is at lp:~qbzr-dev/qbzr/show-merge-
> depth. I've attached a screen shot of this.
>
> If you look at the following revisions in bzr.dev:
> 4193
> 4189.1.1
> 4183.7.1
>
> The dag and merge depths look like this:
> Rev No DAG Merge Depth
> 4193 * 0
> - |\
> 4189.1.1 | * 1
> - | |\
> 4183.7.1 | | * 1
> - | | |
> - | | |
> - |/ |
> - | |
> - | /
> - |/
>
> Shouldn't the merge depth for 4183.7.1 be 2?

The whitespace looks fine in email. And you can just as easily draw the
above as:

  A
  |\
  | B
  |/|
  C D
  |/
  E

Only if you had:

  A
  |\
  | B
  |/|\
  C | D
  | |/
  | X
  |/
  E

Could "D" be considered as a deeper merge.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknPpqMACgkQJdeBCYSNAANnjgCeP8Mb6X9vv6VfYbMpgMrWkRHX
yGsAoMfssVH3XZWGxgFzj5H0rpvbkGUn
=OFSm
-----END PGP SIGNATURE-----

[Gary van der Merwe (garyvdm)]

A
|\
| B
|/|
C D
|/
E

I think merge_sort should take into account which revisions were merged into which. I.e., for the above dag, if to create B you did:

pull D
merge C

Then the parents of B would be [D, C], the merge depth for D = 1, and the graph should be shown as:

But if you did :

pull C
merge D

Then the parents of B would be [C, D], and because D is been merged in C, not the other way around, D's merge depth should increment to 2?

Please see bug 359726.

[Gary van der Merwe (garyvdm)]

Here is a dag that show more clearly that this is a bug:

A
|\
| B
| |\
| | C
|//
E

The merge_depth for C is 1. It should be 2?

[Gary van der Merwe (garyvdm)]

Fixed in rev 4620.