MYSQL/BZR P3: Incomprehensible results of "bzr log -rX..Y"

Additional debug info.

bzr log -n0 --show-ids tag:mysql-6.0.9..mysql-6.0.10 :

------------------------------------------------------------
revno: 3060.2.8
tags: mysql-6.0.10
revision-id: <email address hidden>
parent: <email address hidden>
committer: Jonathan Perkin <email address hidden>
branch nick: mysql-6.0.10-alpha-release
timestamp: Tue 2009-03-03 17:53:18 +0100
message:
  DBUG_* must come with variable definitions to satisfy compilers which require
  that they are all defined together.
------------------------------------------------------------
revno: 3060.2.7
revision-id: <email address hidden>
parent: <email address hidden>
committer: Jonathan Perkin <email address hidden>
branch nick: mysql-6.0.10-alpha-release
timestamp: Tue 2009-03-03 10:59:32 +0100
message:
  Fix previous, missed an #endif
------------------------------------------------------------
revno: 3060.2.6
revision-id: <email address hidden>
parent: <email address hidden>
committer: Jonathan Perkin <email address hidden>
branch nick: mysql-6.0.10-alpha-release
timestamp: Mon 2009-03-02 22:52:37 +0100
message:
  Re-commit changes lost in previous merge.
------------------------------------------------------------
revno: 3060.2.5
revision-id: <email address hidden>
parent: <email address hidden>
committer: Jonathan Perkin <email address hidden>
branch nick: mysql-6.0.10-alpha-release
timestamp: Mon 2009-03-02 18:03:28 +0100
message:
  Avoid 'directives may not be used inside a macro argument' error.
------------------------------------------------------------
revno: 3060.2.4
revision-id: <email address hidden>
parent: <email address hidden>
committer: Jonathan Perkin <email address hidden>
branch nick: mysql-6.0.10-alpha-release
timestamp: Fri 2009-02-27 14:38:57 +0100
message:
   - more C++ comment fixes in C files.
   - don't redefine TRUE/FALSE
------------------------------------------------------------
revno: 3060.2.3
revision-id: <email address hidden>
parent: <email address hidden>
committer: Jonathan Perkin <email address hidden>
branch nick: mysql-6.0.10-alpha-release
timestamp: Fri 2009-02-27 14:02:40 +0100
message:
  No C++ comments in C header files.
------------------------------------------------------------
revno: 3060.2.2 [merge]
revision-id: <email address hidden>
parent: <email address hidden>
parent: <email address hidden>
committer: Jonathan Perkin <email address hidden>
branch nick: mysql-6.0.10-alpha-release
timestamp: Mon 2009-02-23 12:55:35 +0100
message:
  Merge in changes from 6.0.9-release, with the additional change of installing the audit_null plugin
  in RPMs.
    ------------------------------------------------------------
    revno: 2617.33.11
    tags: mysql-6.0.9
    revision-id: <email address hidden>
    parent: <email address hidden>
    committer: J...

When I wrote
       which "bzr log -n0" does *not* print
I meant
       which "bzr log -n0 --show-ids tag:mysql-6.0.9..mysql-6.0.10" does *not* print

once more:
replace tag:mysql-6.0.9..mysql-6.0.10 by tag:mysql-6.0.9..tag:mysql-6.0.10 . Phew.

add a -r and it will be good.

So, arguably bzr missing is misleading here.
bzr log is correct, try 'bzr bzr qlog a b' and you'll clearly see that revid:<email address hidden> being revno:2617,27.11 and tag:mysql-6.0.9 is the right parent of revid:<email address hidden> being revno:3063

So the shortest path from there to tag:mysql-6.0.10 (revno: 3069) is via revno:3064 -> 3069 and that's what bzr log is reporting, I can't see something wrong here.

*But* bzr missing reports a different result because it's supposed to show the difference between the two graphs and doing so without deleting the common parts (which may be considered a bug, although I'm pretty sure it's rare when no criss-cross merges are involved).

It's a tiny bit clearer if you don't use --include-merges since it reveals that the branches have diverged from revid:<email address hidden> (revno:2936 in a and revno:2617.113.15 in b).

So I think the options here are:
- fix missing to not display revisions that are common to both branches (I think it's an unwanted consequence
  of adding --include-merges)
- add a revspec that mimicks the actual behavior (including this "bug")

Hello Vincent. I beg, please don't change the behaviour of "bzr missing --include-merges". It's a very good command which we use to reliably know what are the differences between two branches.

We discussed this for hours with Vincent, and here's a clarification of what I find strange: if you have this graph:
A
| \
B C
| /
D
then "bzr log -rB..D -n0" shows
D
  C
B
but "bzr log -rC..D -n0" shows
D
  C
See, it's assymetric: the "mainline" property of the starting point of the -r range, influences how many revisions you see (3 versus 2).
I don't see the logic behind.
"bzr log -rB..D -n0" seems to show "all that was added to B to reach D" (B, C, D, and I love that). But "bzr log -rC..D -n0" doesn't show "all that was added to C to reach D" (which would be C, B, D).
To me (but I'm not a bzr expert at all), "mainline" is not a key property and I prefer to see the graph as
 A
 / \
B C
 \ /
 D
(i.e. the direction of the "bzr merge" command which the colleague used, does not matter, a merge is just the reconciliation of two revisions...).
I have the latest bzr.dev, revno 4955.
I am fine with having wrong expectations for "bzr log", but then I would like, to close the topic, to be given a definition of what
"bzr log -rX..Y -n0" is expected to return (and ideally a mention of that definition in "bzr help log").
I already know that if there are multiple possible paths from X to Y, what is printed is not always the shortest path from X to Y but, it seems, the "most mainline" path from X to Y (which can easily be 10x bigger than the shortest path in my tests, where the shortest path in "on the right").
By the way, "bzr log -rC..D" (without -n0) rather gives
bzr: ERROR: Start revision not found in left-hand history of end revision.

How to create the graph above:
cd /tmp
/bin/rm -rf test
mkdir test
cd test
bzr init left
cd left
touch foo
touch bar
bzr add .
bzr commit -mA
bzr branch . ../right
echo b > foo
bzr commit -mB
cd ../right
echo c > bar
bzr commit -mC
cd ../left
bzr merge ../right
bzr commit -mD

Just a note about "shortest path", I shouldn't have use shortest at all.
A more correct definition is that log will find the earliest occurrence in the branch.
For mainline revisions there is no ambiguity.
Merged revisions are attached to the first mainline revision that made them part of the branch history.

Said otherwise: the fact that there is a shortest path in revision graph is not relevant
(merging an old revision on the tip will always create a shorter path).
'bzr log' always presents revisions in the same way and presents each revision only once.
To achieve that, revisions are presented in the order they enter the branch history.

Thanks Vincent. So let's forget about "shortest". The definition which you gave is still a bit too hard to parse for me :-)
I am under the impression that "bzr log -rX..Y" (where X is an ancestor of Y) will start from Y, walk up the graph, reach the mainline as soon as possible, walk up the mainline, and leave the mainline as late as possible to reach X.
I'm attaching a graph (from "bzr graph-ancestry") for a test branch "m" which I created; the "bzr log -n0 -r1.1.1..1.1.4", when run in the "m" branch, shows first 1.1.4, then 4 (so, we reached the mainline), 1.1.3 and 1.1.2 (I assume this is because those are merged by 4 and I use -n0?), then 3 (still walking up the mainline), then 1.1.1 (leave the mainline and reach end target). That seems to confirm my interpretation.
Removing -n0, or using -n1, I get a different thing: 1.1.4,1.1.3,1.1.2,1.1.1 (so, the right side of the graph, direct without going through mainline). I'm not sure I understand this difference (should I file a bug report?). With -n2, I get the same as -n0.
Script to recreate my branch:
/bin/rm -rf /tmp/test
mkdir /tmp/test
cd /tmp/test
bzr init m # mainline
cd m
touch foo
bzr add .
bzr commit -mA
bzr branch . ../r # right, to be merged
echo > foo
bzr commit -mB
cd ../r
touch bar
bzr add .
bzr commit -mC
cd ../m
bzr merge ../r
bzr commit -mD
cd ../r
echo > bar
bzr commit -mE
echo a > bar
bzr commit -mF
cd ../m
bzr merge ../r
bzr commit -mG
cd ../r
bzr merge ../m
bzr commit -mH --unchanged
cd ../m
bzr merge ../r
bzr commit -mI --unchanged

I'm honestly not 100% sure what the code for selecting what revisions to display does. I *do* know what the code to decide what the log output looks like. Imagine this case:

 A
 |\
 B C
 | |
 D E
 | |
 F G
 |/
 H

This is how I like to describe our display algorithm (internally called
'merge_sort'):
1) We output revisions in topological order (we give parents before children)
2) We also output a revision after the last revision which did not have it in
the ancestry.

(1) says that C E G have to come before H, as does B D F. It does *not* give a
relative ordering between B D F and C E G. So, for example:
 A B C D E F G H is a topological ordering, as is
 A C E G B D F H and
 A B D F C E G H, etc.
(2) says that C E G has to come after F in the display. Which means that only
 A B D F C E G H fits the constraints.
It also seems to make the ordering 100% stable. (There is only 1 ordering which
fits both constraints 1 & 2). [ISTR there may be 1 edge case, but it is rare]

Anyway, If we draw another graph:

 A
 |\
 B C-.
 | |\ \
 D E F G
 | |/ /
 H I /
 |/ /
 J /
 |/
 K

There are 2 paths to C, with 'G' being the shorter of the two. The merge_sort
output is:
 A B D H C E F I J G K

And I would expect 'bzr log -r C..K' to give
 C E F I J G K
Or in indented form
 C
 E
  F
 I
J
 G
K

Summary of John's feedback from IRC: the output of "bzr log -rX..Y" is dictated by

- take the full graph of the branch
- serialize it according to those rules:
  * a revision X will appear after any child revision Y (topological) (when using --forward, replace "after" by "before"),
  * further if Y's left-hand parent (Z) does not contain X, then X will appear between Y and Z in the output"
- output only the [A...B] section of the serialized output

What remains to decide is if this applies to -n0, and what is the influence of -n on the above rules...

And 30 minutes after killing the above "bzr branch" job on my local machine, the bzr process on the remote machine is still running at 100% CPU. I suspect that this is a bug. There should be reasonably periodic detection, on the remote side, that the local side process has gone away. Otherwise the warning, even if it is printed, loses interest (it warns you, you control-C your bzr command, but it still hogs the remote machine for a long time).

Some piece of information, maybe useless: on the local machine, when I killed bzr after it had exchanged 300MB on the network and ran for 4 hours, my branch was only 8KB.

Sorry, the two last posts are about another bug report, I mixed Firefox tabs. Please ignore them.

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

GuilhemBichot wrote:
> Summary of John's feedback from IRC: the output of "bzr log -rX..Y" is
> dictated by
>
> - take the full graph of the branch
> - serialize it according to those rules:
> * a revision X will appear after any child revision Y (topological) (when using --forward, replace "after" by "before"),
> * further if Y's left-hand parent (Z) does not contain X, then X will appear between Y and Z in the output"
> - output only the [A...B] section of the serialized output
>
> What remains to decide is if this applies to -n0, and what is the
> influence of -n on the above rules...
>

It would apply more to -n0 than to -n1.

I also can't confirm that this is the actual logic. But it is the logic
that would make sense to me.

John
=:->

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

iEYEARECAAYFAktQh0QACgkQJdeBCYSNAANwnACgtSoc/Kb67DT/jOkrdMxy0V9G
PqgAnjswh5+LtJi6k2imZmwLaKJQy0Di
=PZoq
-----END PGP SIGNATURE-----

So bzr help log indeed says:

  The filtering, ordering and information shown for each revision can
  be controlled as explained below. By default, all revisions are
  shown sorted (topologically) so that newer revisions appear before
  older ones and descendants always appear before ancestors. If displayed,
  merged revisions are shown indented under the revision in which they
  were merged.

then

  When logging a range of revisions using -rX..Y, log starts at
  revision Y and searches back in history through the primary
  ("left-hand") parents until it finds X. When logging just the
  top level (using -n1), an error is reported if X is not found
  along the way. If multi-level logging is used (-n0), X may be
  a nested merge revision and the log will be truncated accordingly.

The 'through the primary ("left-hand") parents until it finds X' ambiguity (which parent) is decided by the previous rule (newer revisions appear before older ones) which should be understood applied to the whole graph.

I'm not sure we can really make it clearer, at least it seems *I* can't :)

Regarding 'using -n1, I get a different thing: 1.1.4,1.1.3,1.1.2,1.1.1'.
 I can't find a good explanation for bzr behaviour here... there is kind of a logic to show the same level from the start revision to the end and showing only one level because that's what -n1 ask for, but it's kind of hairy and surprising.

Displaying '5' (1.1.4 mainline descendant), '4', '3' (1.1.1 mainline descendant) seems more logical. On the other hand, -r3..5 will produces the same result and we say we truncate based on the revisions given.

So I tracked it down to _is_obvious_ancestor() that uses a shortcut based solely on the revnos to decide that a linear presentation is possible because 1.1.1 and 1.1.4 are both on the '1.1' "development line".

The disturbing point being that '4' is totally ignored in that case, I'm pretty sure this wasn't anticipated. What *was* anticipated was the ability to start the log at a nested revision without a hanging indentation.

Then there is also a bug that 1.1.4 is *not* indented.
This is undesirable also because when using 'log -n0 -r1.1.1..1.1.4 --forward' it *is* indented and appears as an ancestor of '4' when it is a descendant.

Right, so 1.1.4 indentation is not a bug, it's a feature, but I can't find tests for it :-/

Hello Vincent; I wonder, about your two last comments: did you find a bug?

So, I was surprised by the way the revisions were indented but it's not a bug, flattening
the first revisions is indeed the intended behavior but it doesn't apply to your example
(it applies to your first comment though).

But regarding the revno '4' not being displayed... your example tricked me as it presents
'1.1.4' as if its parents were '4' and '1.1.3'.
In fact your script build it with parents '1.1.3' '4' (merging "mainline" into branch where
the others merge branch into into mainline), bzr *cares* about parent ordering.

So '4' doesn't come into play here since when '-n1' is used, 'bzr log', *as a special case*,
follows only the left-hand ancestry (explicitly ignoring the merged revisions) which rightly
produces '1.1.4', '1.1.3', '1.1.2' and '1.1.1'.

So, regarding my last two comments, no bug here.

I've added tests to keep track of the case.

Hello Vincent. If I understand you correctly, when I do "bzr log -nX -r1.1.1..1.1.4":
- if X is 0, what happens is what is in "bzr help log" which you pasted, we start from 1.1.4, walk back to left-parent (4), display revisions which it has merged (due to -n0) (1.1.3,1.1.2), goes up to the left-parent (3) at which point it can reach 1.1.1. Ok.
- if X is 1, what happens is that we start from 1.1.4, walk back to left-parent, which this time isn't 4 as above but 1.1.3?
Do we have two definitions of what "left" is, depending on -n0/-n1?

> - if X is 0, what happens is what is in "bzr help log" which you pasted, we start from 1.1.4, walk back to left-parent (4),

Oops, you fall in the same trap than me, '4' is the *right* parent not the left one.

Ah right, so: if X is 0, we start from 1.1.4, walk back to right-parent (4). Isn't that a contradiction with the pieces of "bzr log" which you pasted ('log starts at revision Y and searches back in history through the primary ("left-hand") parents until it finds X')?

In that case, the line that is followed includes '4' as a second (right) parent because it's merged *into* '1.1.4',
we don't go to the mainline but just encounters a revision which *is* on mainline:
1.1.4
   | \
   | 4
   | /
1.1.3
   |
1.1.2
   |
1.1.1

So left-hand ancestry (only) may be more precise than mainline in my previous explanation.

Hello Vincent. Ok, but one thing is still mysterious. In the branch for which I posted a graph, "bzr log -n0 -r1.1.1..1.1.4", when run in the "m" branch, shows first 1.1.4, then 4 (because 1.1.4 merged it?), 1.1.3 and 1.1.2 (still going through left parents?), then 3, then 1.1.1. But "bzr help log" says "If displayed, merged revisions are shown indented under the revision in which they were merged", so shouldn't I see 3 right below 4?
And, if the right parent of 1.1.4 is 4, and the left parent of 1.1.4 is 1.1.3, why do I see such indentation:
1.1.4
4
   1.1.3
?
Why isn't 4 indented and 1.1.3 not indented?
There may be no real interest in discussing this though, because it looks like the output of "bzr log -rX..Y" is not for mere mortals (like me) when there are merges :-)

> Why isn't 4 indented and 1.1.3 not indented?

As said in Comment #21, the first revisions are "flattened" so that we display them *not* indented until the "leftmost"
(of all the displayed revisions) one is reached, from there the indentation reflects the merge depth.

 > "bzr log -rX..Y" is not for mere mortals (like me) when there are merges :-)

That may be why the 'Tips & tricks' section in 'bzr log --help' points too qlog and viz :-/

Today a colleague had another case which I cannot explain.
I get https://code.launchpad.net/~mysql/mysql-server/mysql-next-mr-bugfixing
and do, in order to see the ancestry of a revision:
bzr --no-plugins --no-aliases log -n0 -r 'revno:1..revid:<email address hidden>'
(same scenario as Bug 519862 by the way).
This returns 2300+ more revisions than the following bullet-proof way:
bzr branch -r 'revid:<email address hidden>' --no-tree . ../tmp
cd ../tmp
bzr --no-plugins --no-aliases log -n0 -r 'revno:1..revid:<email address hidden>'

Those 2300 additional revisions seem to be revisions which landed into the mainline in the same merge as sven.etc.

Is it normal that the first command returns revisions which are in fact not in the ancestry of sven.etc?
Is it explained by "bzr help log"?
Thanks.

Guilhem, I'll mark this bug as a duplicate of bug #476293, feel free to disagree by providing more input.

Sorry Guilhem, I didn't notice your last comment when I marked the bug as a duplicate,
 but you've already filed a different bug for that issue so let's track it there.

I'd like the duplicate status to be removed. 476293 is about about expected errors in "bzr log -rX..Y", while the present bug is about understanding the output of "bzr log -rX..Y".
So first I'd like a reply on my post of 2010-02-10.
Second, yet another colleague was confused by "bzr log -rX..Y" today, here's a digest of what he wrote:
<quoting him>
sh> bzr branch -rtag:mysql-5.1.41 mysql-5.1 5.1.41
sh> bzr branch -rtag:mysql-5.1.42 mysql-5.1 5.1.42
sh> (cd 5.1.41 && bzr log -n0 --show-ids | grep "<email address hidden>")
sh> (cd 5.1.42 && bzr log -n0 --show-ids | grep "<email address hidden>")
parent: <email address hidden>
revision-id: <email address hidden>
sh> (cd 5.1.42 && bzr log -n0 --show-ids -rtag:mysql-5.1.41.. | grep "<email address hidden>")
parent: <email address hidden>
i.e
1) <email address hidden> is not in 5.1.41 = correct
2) <email address hidden> is in 5.1.42 = correct
3) <email address hidden> does now show in revisions created from 5.1.41 to 5.1.42 = bug ?
</quoting him>
See, he had the same expectation that with -rX..Y he should be seeing the revisions created from 5.1.41 to 5.1.42.
I explained to him that a mere mortal cannot understand what "bzr log -rX..Y" is expected to return, and that he should use "bzr missing --include-merges" between mysql-5.1.41 and mysql-5.1.42 instead.
Still, his interpretation matches the one I had before this bug report was started. I think people in the MySQL group are generally confused by "bzr log -rX..Y". I suspect "bzr help log" could be clarified a bit.

> Today a colleague had another case which I cannot explain.
> I get https://code.launchpad.net/~mysql/mysql-server/mysql-next-mr-bugfixing
> and do, in order to see the ancestry of a revision:
> bzr --no-plugins --no-aliases log -n0 -r 'revno:1..revid:<email address hidden>'
> (same scenario as Bug 519862 by the way).

Ouch, 60281 revisions to be precise.

> This returns 2300+ more revisions than the following bullet-proof way:
> bzr branch -r 'revid:<email address hidden>' --no-tree . ../tmp
> cd ../tmp
> bzr --no-plugins --no-aliases log -n0 -r 'revno:1..revid:<email address hidden>'

57800 revisions.

> Those 2300 additional revisions seem to be revisions which landed into the mainline in the same merge as sven.etc.

It's a bit more involved than that, but roughly yes, they shouldn't appear in log.

This is best understood with qlog, see bug #540848 for a recipe.
Following the instructions there:
- issuing bzr qlog sven mr-bugfixing
- scroll down until the blue 'sven' label, select the revision (3030 revid:<email address hidden>)
- click on the children link (3023.46.2: merged fixes for BUG#39934 to 5.1-rpl+3)
- 3023.46.2 revid:<email address hidden> is the revision that merged 3030 revid:<email address hidden> into 3023.46.1 revid:<email address hidden>)
- from there, the next revision presented by qlog is: 3023.74.34 revid:<email address hidden>

This is the first (among the 2300) spurious revision.

> Is it normal that the first command returns revisions which are in fact not in the ancestry of sven.etc?

No.

> Is it explained by "bzr help log"?

No, it's a bug and it should be fixed.

At first glance, the problem seems to be that the way we flatten the graph and the way bzr log filters it interact badly
on complex histories (not using append_revisions_only is certainly an aggravating factor here).

I'm investigating.

Regarding:
> 3) <email address hidden> does now show in revisions created from 5.1.41 to 5.1.42 = bug ?

Which branch at which tip was used to expose that ?
in mr-bugfixing 3126 <email address hidden>:
bzr log -n0 --show-ids -rmysql-5.1.41..mysql-5.1.42 | grep "<email address hidden>"
                    parent: <email address hidden>
                    revision-id: <email address hidden>

So the revision is displayed here not missing, so it doesn't sound like the same bug.

Merci Vincent.
>Regarding:
> > 3) <email address hidden> does now show in revisions created from 5.1.41 to 5.1.42 = bug ?
>Which branch at which tip was used to expose that ?
>in mr-bugfixing 3126 <email address hidden>:
>bzr log -n0 --show-ids -rmysql-5.1.41..mysql-5.1.42 | grep "<email address hidden>"
> parent: <email address hidden>
> revision-id: <email address hidden>
>So the revision is displayed here not missing, so it doesn't sound like
>the same bug.
Please grab https://code.launchpad.net/~mysql/mysql-server/mysql-5.1, at revision id
<email address hidden>, then run:
 bzr log -n0 --show-ids -r tag:mysql-5.1.41..tag:mysql-5.1.42 | grep "<email address hidden>"
it only returns:
parent: <email address hidden>
so it looks like missing.

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

Vincent Ladeuil wrote:
>> Today a colleague had another case which I cannot explain.
>> I get https://code.launchpad.net/~mysql/mysql-server/mysql-next-mr-bugfixing
>> and do, in order to see the ancestry of a revision:
>> bzr --no-plugins --no-aliases log -n0 -r 'revno:1..revid:<email address hidden>'
>> (same scenario as Bug 519862 by the way).
>
> Ouch, 60281 revisions to be precise.
>
>> This returns 2300+ more revisions than the following bullet-proof way:
>> bzr branch -r 'revid:<email address hidden>' --no-tree . ../tmp
>> cd ../tmp
>> bzr --no-plugins --no-aliases log -n0 -r 'revno:1..revid:<email address hidden>'
>
> 57800 revisions.
>
>> Those 2300 additional revisions seem to be revisions which landed into
> the mainline in the same merge as sven.etc.
>
> It's a bit more involved than that, but roughly yes, they shouldn't
> appear in log.

I'm guessing it is a bug in our heuristic of how to compute "what merged
X". meaning if you have

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

And you do 'bzr log -r 1..C' we intentionally show D (IIRC). I think if
the nesting is directly deeper, we would try to log that:

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

'bzr log -r D' will try to show E and F as well. I wouldn't be surprised
if the issue is that you have something like:

A
|\
| B
| |\
| C D
| |/
| E
| |
| F
| :
| Y
|/
Z

And doing 'bzr log -r D' is causing all of E=>Y to get logged as well.
Having 'show me what revisions merged the revision I'm interested in' is
intented. I'm not sure if this is just an unfortunate side-effect of
that decision.

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

iEYEARECAAYFAkukWpgACgkQJdeBCYSNAAN/1ACgsilYgWlAAKw83UGWdPJREzud
V3kAmQHefLWAtEvLCh5y7QNvII/SXfZk
=AbKB
-----END PGP SIGNATURE-----

> And you do 'bzr log -r 1..C' we intentionally show D (IIRC). I think if
> the nesting is directly deeper, we would try to log that:

Close enough, we don't show D. Before the fix proposed at https://code.edge.launchpad.net/~vila/bzr/474807-log-filter-ancestry/+merge/21829 , we *were* showing all the ancestry leading to D but not D itself.

The fix is show only the ancestry related to C.

The last case mentioned by Guilhem is different, it's about the other end of the revision range,
I'm investigating.

So, long story short:

Using branch with tip 3367 revid:<email address hidden>,
<email address hidden> (davi for short, revno 3200)

> 1) <email address hidden> is not in 5.1.41 = correct

davi for short is not in 5.1.41 history.

2) <email address hidden> is in 5.1.42 = correct

davi is in 5.1.42 history.

3) <email address hidden> does now show in revisions created from 5.1.41 to 5.1.42 = bug ?

davi entered the branch history *before* 5.1.41.

BUT in the branch with tip 3126 revid:<email address hidden>,

davi entered the branch history *after* 5.1.41.

Roughly speaking, 'bzr log' flatten the history graph and it *appears* there is one path from 5.1.41 to 5.1.42.

The way the graph is flatten is that, for a merge, we display the right-hand ancestry before the left-hand
one, the reason being that the purpose of the merge is to bring in new revisions that the user is
more likely to be interested in than the revisions that were added to the trunk, before the merge,
but after that the merged branch has diverged. Moreover, a revision is only shown once: in the merged revision on the *mainline* that merged it first, the reason being that any other choice will not be stable
(i.e. may give different result for a given branch at various points in time).
That last point may change between different branches since not all branches have
the same mainline revisions.

In a workflow where the shared branch(es) doesn't use append_revisions_only, is that the later constraint
is not respected and that leads to different logs, depending on who merged what and when
and who *pushed* to the shared branch and when.
As a consequence, depending on how the branch is constructed, different paths will be shown.

This is less surprising when you realize that every branch has its own history (everybody commits on its own tip) but if you want to *share* a branch history, then everybody has to participate in the same way.
I.e. merges should occur on trunk and be imported by everybody.

To backtrak a bit in the discussion, establishing which revisions are part of 5.1.42 history but not part
of 5.1.41 history without depending on the way the branch itself has been built, you need to build
both branches and use bzr missing. Or do bzr log in a branch whose tip is 5.1.42.

Could we fix log ?

Not without respecting the two constraints above: 1) show right-hand histroy before left hand, 2) show each revision once in the history of its first mainline revision.
These two constraints are required to obtain stable revnos.

I think there was some discussion about having a log option to totally avoid using revnos,
in that case there may be a different way to address the problem but roughly it will be doing what missing does.

Thanks Vincent. Your explanations are close to fully understandable for me :-)
The way I understand what "bzr log -r X..Y -n0" does is, inspired from a discussion with John earlier in the bug report:
- generate the full "bzr log -n0", in accordance with rules which you specified and with "bzr help log".
- in the textual output above, eliminate everything which is below X (i.e. has a line number greater than X's) and everything which is above Y.
I verified that this understanding matches what I get with "bzr log -n0 -r mysql-5.1.41..mysql-5.1.42".
I wonder if the observed output also matches this paragraph of "bzr help log":

   When logging a range of revisions using -rX..Y, log starts at
   revision Y and searches back in history through the primary
   ("left-hand") parents until it finds X. When logging just the
   top level (using -n1), an error is reported if X is not found
   along the way. If multi-level logging is used (-n0), X may be
   a nested merge revision and the log will be truncated accordingly.

Your are saying that you're leaving out revisions because "the user is more likely to be interested in" some other revisions. What makes you think that the user isn't interested in seeing *all* revisions?

Can you name one practical example where a user decidedly only wants to see half of the changes that actually happened, and leaving the decision which half to show to the vcs will actually always show the correct half?

You write that "if you want to *share* a branch history, then everybody has to participate in the same way.
I.e. merges should occur on trunk and be imported by everybody." So what constitutes a trunk? In our example, the trunk is the mysql-5.1.41 .. mysql-5.1.42 line. From the point of view of this trunk, the history looks as follows:

some ancestor is committed
mysql-5.1.41 is committed
davi is merged
mysql-5.1.42 is committed

The merge of davi into trunk may have happened at the tip of the trunk, but in any case it is part of the merges that happened to trunk between mysql-5.1.41 and mysql-5.1.42.

You write that you can't fix bzr log without violating the two constraints. But consider this mockup log:

mysql-5.1.42
  mysql-5.1.41
davi
some ancestor

How are the two constraints violated there? The right-hand history is shown first, and each revision is only shown once.

If I create a similar structure manually, I always get this kind of output. Can you show me a way to reproduce a similar structure from scratch and get the output you are postulating is correct?

For comparison, git's definition of "git log X..Y" is as follows:

"revisions reachable from Y, but not from X"

>>>>> Daniel Fischer <email address hidden> writes:

    > Your are saying that you're leaving out revisions because "the
    > user is more likely to be interested in" some other revisions.

No, I said these revisions are shown *before* the others.

    > What makes you think that the user isn't interested in seeing
    > *all* revisions?

This is what this bug was about no ? If the user wants to see all
revisions he doesn't specify a *range*, This bug is about
'Incomprehensible results of "bzr log -rX..Y"', it's not about seeing
all revisions even if some explanations provided here (no matter how bad
they are) apply to both seeing all revisions and seeing only a part of
these revisions *defined as a range* applied to a *graph* which leaves
room for various ways to chose the revisions shown (which is not
contradictory with always showing the same revisions for a given branch
as long as some assumptions are verified).

    > Can you name one practical example where a user decidedly only
    > wants to see half of the changes that actually happened,

This sentence is too vague for me to be interpreted in the context of
this bug where we're talking of very precise graph shapes. What is
'half' ?

Guilhem reported that he was seeing revisions that weren't related to
his request, the proposed fix doesn't show these revisions anymore.

    > and leaving the decision which half to show to the vcs will
    > actually always show the correct half?

Given your further remarks, you consider the range operator 'X..Y' as
described in the git documentation as being the graph difference between
X and Y. The git documentation doesn't apply to the bzr *range*
operator.

The graph difference you're after is provided by the 'bzr missing'
command and this has been mentioned numerous times in this thread.

If 'bzr missing' is bogus it should be fixed (see comment #5), Guilhem
explicitly said (comment #6) that *this* bug wasn't about missing.

    > You write that "if you want to *share* a branch history, then
    > everybody has to participate in the same way. I.e. merges should
    > occur on trunk and be imported by everybody." So what constitutes
    > a trunk? In our example, the trunk is the mysql-5.1.41
    > .. mysql-5.1.42 line.

How do you define this "line" in the graph associated to a branch ?

The path in the ancestry to goes from mysql-5.1.41 to mysql-5.1.42 ?
Which one do you chose when several exist ?

'bzr log' defines a total order on the revisions for a given tip (see
other comments in this bug), from this total order the range operator
can be defined with variations on whether the boundaries should be
included or not, etc.

Said otherwise it defines a projection of the graph onto a line. The
range operator can then be defined on this line.

The line chosen by 'bzr log' is unambiguously defined but from there
some "dwim" have been applied:

- the range is inclusive so X..X is not empty but instead specify
  revision X itself, with its merge revisions depending on '-n' or
  '--include-merges'

- each revisions is displayed with a depth, with, again., some dwim for
  the start of the range,

- the range can be reversed, with again some dwim so that mer...

> This is what this bug was about no ? If the user wants to see all
> revisions he doesn't specify a *range*, This bug is about

... what that range means, yes.

> Given your further remarks, you consider the range operator 'X..Y' as
> described in the git documentation as being the graph difference between
> X and Y. The git documentation doesn't apply to the bzr *range*
> operator.

I'm perfectly aware of the git documentation not applying to bzr. I gave
it as an example of what I think a range should mean. Most revision
control systems use similar definitions, but git's is the shortest I've
seen.

> The graph difference you're after is provided by the 'bzr missing'
> command and this has been mentioned numerous times in this thread.

I know. Several tools we use internally also call into bzrlib directly
to calculate the graph difference.

> How do you define this "line" in the graph associated to a branch ?
>
> The path in the ancestry to goes from mysql-5.1.41 to mysql-5.1.42 ?
> Which one do you chose when several exist ?
..
> Except for the branch where what occurred was:
>
> some ancestor is committed
> davi is merged (or committed, whatever)
> mysql-5.1.41 is merged
> mysql-5.1.42 is committed
>
> These two branches define *different* total orderings of the revisions,
> so the range operator give different results.

The ordering of revisions is a result of transforming a graph into a
linear structure. At the point where mysql-5.1.41 is merged in your
scenario, the graph looks like this (we are at "B"):

some_ancestor
   | |
davi mysql-5.1.41
   | /
   A /
    \ /
     B
     |
   continued to mysql-5.1.42 later

Following bzr log's definition of X..Y, mysql-5.1.41..mysql-5.1.42 means:

1) start at mysql-5.1.42
2) follow the left-hand ancestors back up
3) find B, which introduces mysql-5.1.41, and stop

So essentially, the range mysql-5.1.41..mysql-5.1.42 becomes the range
B..mysql-5.1.42 because bzr log would not follow a right-hand parent,
according to bzr help log. It still displays mysql-5.1.41 because
without -n0, it won't even find it, and with -n0, it will show all
merged revisions, but what it really does is stop at B.

What I'm saying is that this approach of linearising the graph is wrong
precisely because it allows for this kind of ambiguity. In this example,
mysql-5.1.41 doesn't actually come *after* davi, it happens *at the same
time*. The ordering that you speak of is purely artificial and the
ambiguity is an artefact of that artificial ordering.

If this specific scenario was the only one, the graph could be
linearised as follows:

some_ancestor
davi
mysql-5.1.41
mysql-5.1.42

And this seemingly indicates a different relationship between revisions
than what I gave as what must have happened, which could be linearised
as follows:

some_ancestor
mysql-5.1.41
davi
mysql-5.1.42

But both of these orderings are wrong. In the first case, mysql-5.1.41
is not actually *based* on davi. Only the merge revision which brings it
in is. In the second case, davi is likewise not *based* on mysql-5.1.41.
Only the merge that brings it in is.

While bzr log's definition is stable and always results in the...

>>>>> Daniel Fischer <email address hidden> writes:

<snip/>

    >> Given your further remarks, you consider the range operator
    >> 'X..Y' as described in the git documentation as being the graph
    >> difference between X and Y. The git documentation doesn't apply
    >> to the bzr *range* operator.

    > I'm perfectly aware of the git documentation not applying to
    > bzr.

Thanks for confirming.

    > I gave it as an example of what I think a range should mean.

    > Most revision control systems use similar definitions, but git's
    > is the shortest I've seen.

Since it defines no order, yes, it's easier to make it short. But it's
still irrelevant in bzr log context where we want to define a range
operator.

    >> The graph difference you're after is provided by the 'bzr
    >> missing' command and this has been mentioned numerous times in
    >> this thread.

    > I know. Several tools we use internally also call into bzrlib
    > directly to calculate the graph difference.

<snip/>

    > The ordering of revisions is a result of transforming a graph into a
    > linear structure. At the point where mysql-5.1.41 is merged in your
    > scenario, the graph looks like this (we are at "B"):

    > some_ancestor
    >> |
    > davi mysql-5.1.41
    >> /
    > A /
    > \ /
    > B
    >>
    > continued to mysql-5.1.42 later

    > Following bzr log's definition of X..Y, mysql-5.1.41..mysql-5.1.42
    > means:

    > 1) start at mysql-5.1.42
    > 2) follow the left-hand ancestors back up
    > 3) find B, which introduces mysql-5.1.41, and stop

No.

The doc is misleading as you well know if you followed this bug.

The full graph is ordered by merge_sort and then then range is applied.

There are special cases which make the code and the doc less clear but
they don't apply here.

<snip/>

    > What I'm saying is that this approach of linearising the graph is
    > wrong

Because you don't have a use for it doesn't mean it's wrong.

    > precisely because it allows for this kind of ambiguity.

There is no ambiguity for a given branch, *this* is valuable for the dev
maintaining the branch. Did I merge trunk before or after this ?. Can I
reproduce this bug at this revision ? Did I mistake when resolving the
conflicts at this point ? etc.

    > In this example, mysql-5.1.41 doesn't actually come *after* davi,
    > it happens *at the same time*.

A total ordering can't cope with "same time".

    > The ordering that you speak of is purely artificial and the
    > ambiguity is an artefact of that artificial ordering.

There is nothing artificial here, different people proceed differently,
this is recorded.

    > If this specific scenario was the only one, the graph could be
    > linearised as follows:

    > some_ancestor
    > davi
    > mysql-5.1.41
    > mysql-5.1.42

    > And this seemingly indicates a different relationship between revisions
    > than what I gave as what must have happened, which could be linearised
    > as follows:

    > some_ancestor
    > mysql-5.1.41
    > davi
    > mysql-5.1.42

    > But both of these orderings are wrong. In the first case, mysql-5.1.41
    > is not actually *b...

It is probably clear to everybody but in case: there were two issues in this bug report lately.
1) the "sven" issue (grep for "sven" above), which was a bug in "bzr log", which Vincent fixed, thank you Vincent!
2) the incomprehension of what the definition of "bzr log -rX..Y" is (the "davi" issue and the "mysql-6.0.9" issue). Vincent and John have explained the definition; afterwards there is me who concludes that this behaviour is not for mere mortals, and there is Daniel who says this behaviour is useless - to which I agree; I just assumed that it had some usefulness for someone very smart, which is why I said "not for mere mortals"; to me there is no usefulness in .
"bzr missing" is indeed a good workaround which I use, though it has the drawback of requiring creation of temporary branches, something like
bzr branch . -rX ../tmp_X --no-tree # fast if shared repo, impossibly slow otherwise
bzr branch . -rY ../tmp_Y --no-tree
cd ../tmp_X
bzr missing ../tmp_Y
cd ..
rm -rf tmp_X tmp_Y
(I actually have a script which does exactly this, which I use as a replacement for "bzr log -rX..Y" as this doesn't do what I expected).
I hope to have clarified the different positions without offending anybody :-)

grmbl, some random keystroke sent the comment while I was typing. The final version:
It is probably clear to everybody but in case: there were two issues in this bug report lately.
1) the "sven" issue (grep for "sven" above), which was a bug in "bzr log", which Vincent fixed, thank you Vincent!
2) the incomprehension of what the definition of "bzr log -rX..Y" is (the "davi" issue and the "mysql-6.0.9" issue). Vincent and John have explained the definition; afterwards there is me who concludes that this behaviour is not for mere mortals, and there is Daniel who says this behaviour is useless - to which I agree; I just assumed that it had some usefulness for someone very smart, which is why I said "not for mere mortals"; to me there is no usefulness in showing a path which is hard to predict).
"bzr missing" is indeed a good workaround which I use, though it has the drawback of requiring creation of temporary branches, something like
bzr branch . -rX ../tmp_X --no-tree # fast if shared repo, impossibly slow otherwise
bzr branch . -rY ../tmp_Y --no-tree
cd ../tmp_X
bzr missing ../tmp_Y
cd ..
rm -rf tmp_X tmp_Y
(I actually have a script which does exactly this, which I use as a replacement for "bzr log -rX..Y" as this doesn't do what I expected).
I hope to have clarified the different positions without offending anybody :-)

> Because you don't have a use for it doesn't mean it's wrong.

Not because I don't have a use for it, but because it doesn't provide
useful results for a development model that bzr otherwise supports.

> There is no ambiguity for a given branch, *this* is valuable for the dev
> maintaining the branch. Did I merge trunk before or after this ?

This, again, requires a specific development model.

>. Can I reproduce this bug at this revision ? Did I mistake when resolving the
> conflicts at this point ? etc.

These questions can actually be answered in the wrong way unless you use
said specific development model.

> A total ordering can't cope with "same time".

I noticed. :)

> > But both of these orderings are wrong. In the first case, mysql-5.1.41
> > is not actually *based* on davi.
>
> It is. In this branch.

No, it's not. What is based on davi is a merge revision that brings in
mysql-5.1.41. But that revision is not mysql-5.1.41.

> A bug found in this branch may not appear in
> another branch. The code there may not even be complied, not all
> combinations are equal.

Any two branches that contain the same set of commits should, in the
end, contain the same code.

> I fail to see the reasoning here and you obviously haven't been using a
> workflow where each commit on the trunk brings a significant change and
> where using 'bzr log -n1' *is* meaningful.

I have, but only on smaller-scale projects. MySQL is too large for this.
A merge to trunk can bring in in tens or hundreds of bug fixes
accumulated from many development branches. They are grouped more or
less arbitrarily and bzr log -n1 is quite meaningless here.

For smaller projects, I agree that it is meaningful, but then those
would work equally well with svn. A small number of committers and short
paths between development and merge to trunk.

> Many users are perfectly happy to rely on this ordering, if you don't
> want to, feel free to ignore it.

Well, I can't, since for me it means that bzr log leaves out half of the
history every time it encounters a merge.

I would like to ignore the ordering and tell bzr log that it should just
not try to bring any sort of order to the changes, but there is no way
to do that.

In fact, a chronological listing (by timestamp) of the graph difference
between two revisions is what we need, but bzr log can't produce it.
There is a workaround involving bzr missing, which requires creating two
separate branches at the two revisions we want to compare. This takes
quite long with a repository the size of MySQL. Hence, the disappointment.

> In different ways. The end result will be the same, the history will be
> different, bzr log is here to explore this history.

It only lets me explore one possible history, though. It's like
reconstructing a historic war from propaganda issued by any *one*
government involved in it.

> No, have a look at branches that use either append_revisions_only or
> implement an equivalent workflow. None of them requires a central
> server (as in requiring a connection to the server as opposed, to, well,
> distributed).

I'm not saying that this makes no sense with *all possible workflows*.

I...

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

Daniel Fischer wrote:
>> Because you don't have a use for it doesn't mean it's wrong.
>
> Not because I don't have a use for it, but because it doesn't provide
> useful results for a development model that bzr otherwise supports.
>
>> There is no ambiguity for a given branch, *this* is valuable for the dev
>> maintaining the branch. Did I merge trunk before or after this ?
>
> This, again, requires a specific development model.
>
>> . Can I reproduce this bug at this revision ? Did I mistake when resolving the
>> conflicts at this point ? etc.
>
> These questions can actually be answered in the wrong way unless you use
> said specific development model.
>
>> A total ordering can't cope with "same time".
>
> I noticed. :)
>
>> > But both of these orderings are wrong. In the first case, mysql-5.1.41
>> > is not actually *based* on davi.
>>
>> It is. In this branch.
>
> No, it's not. What is based on davi is a merge revision that brings in
> mysql-5.1.41. But that revision is not mysql-5.1.41.
>
>> A bug found in this branch may not appear in
>> another branch. The code there may not even be complied, not all
>> combinations are equal.
>
> Any two branches that contain the same set of commits should, in the
> end, contain the same code.
>
>> I fail to see the reasoning here and you obviously haven't been using a
>> workflow where each commit on the trunk brings a significant change and
>> where using 'bzr log -n1' *is* meaningful.
>
> I have, but only on smaller-scale projects. MySQL is too large for this.
> A merge to trunk can bring in in tens or hundreds of bug fixes
> accumulated from many development branches. They are grouped more or
> less arbitrarily and bzr log -n1 is quite meaningless here.

Except it scales fairly well to integration branches and collaborated
feature branches, etc. The reason we use a number rather than just a
flag is so that you can do 'bzr log -n2, bzr log -n3', etc. If
jointly-developed branches used append_revisions_only, at a deeper
scale, the view would still be useful.

As a side point, though, I still see a lot of "merged this one bugfix
from 5.1 into 6.0" sort of commits. Which still benefit from a collapsed
mainline. I'm sure there would be some noise. But seeing "these 20
bugfixes landed into 5.1, and then '20 bugfixes from 5.1' landed in 6.0
would still be useful". And using bzr log -n2 would give you the
summaries in a fairly meaningful manner.

Even better, 'bzr qlog' (and perhaps viz now?) would let you do this
dynamically, and let you see "oh, I wonder what 20 happened here",
expand it one time to see the list-of-20, expand a child again to see
the details of one of those bugfixes.

>
> For smaller projects, I agree that it is meaningful, but then those
> would work equally well with svn. A small number of committers and short
> paths between development and merge to trunk.
>
>> Many users are perfectly happy to rely on this ordering, if you don't
>> want to, feel free to ignore it.
>
> Well, I can't, since for me it means that bzr log leaves out half of the
> history every time it encounters a merge.
>
> I would lik...

Bonjour Vincent. I picked up one sentence in your discussion with Daniel:
"The doc is misleading as you well know if you followed this bug."
That is one thing which I would like to be improved. I had the impression that the real behaviour of "bzr log -rX..Y" is not well explained in "bzr help log", and reading your words confirms it, so I would like to ask: could the documentation be fixed?
I think it's this text which you are describing as misleading:
  When logging a range of revisions using -rX..Y, log starts at
  revision Y and searches back in history through the primary
  ("left-hand") parents until it finds X. When logging just the
  top level (using -n1), an error is reported if X is not found
  along the way. If multi-level logging is used (-n0), X may be
  a nested merge revision and the log will be truncated accordingly.
I would try to express that what happens is that the full log is created (or maybe not but it feels like it for the user) and then a simple "interval filtering" is applied to it). The details about -n1 and -n0 are important to keep (maybe rephrased).
If the doc was changed, it would at least help me explain to people how the command is not doing what they expect; it would decrease the amount of confused people in the future. Thanks for considering this.

Hello. After the healthy discussions above regarding what "bzr log -n0 -rX..Y" does, and whether it's right, and whether it should do something else instead, I'd like to recap and get some feedback from Canonical:
- I agree that the current behaviour of -rX..Y is useful for some workflows (which Vincent described), and I agree that for our workflow it is not useful (non-mainline revisions are important for us, so we don't want to miss a revision because "bzr log" excluded it because it was ordered out of [X..Y] because it's not mainline). Isn't a graph difference (like graph.difference()) a better solution which would give useful results in all types of workflows? Is there a case where the current behaviour of -rX..Y is superior to a graph difference?
- clearly "bzr missing" does the graph difference which we need; it's a workaround, though not perfect (requires a shared repository which you don't always have under hand)
- Thus, would Canonical be open to changes to "bzr log -rX..Y"? change the default behaviour? introduce an optional configurable behaviour? nope?
- if no change is possible, could "bzr help log" be fixed (see my just previous post)?
Thanks!

>>>>> GuilhemBichot <email address hidden> writes:

<snip/>
    > - Thus, would Canonical be open to changes to "bzr log -rX..Y"?
    > change the default behaviour? introduce an optional configurable
    > behaviour? nope?

See bug #320119 and the proposed fix https://code.edge.launchpad.net/~vila/bzr/320119-exclude-ancestry/+merge/23394

    > - if no change is possible, could "bzr help log" be fixed (see my
    > just previous post)?

See bug #557307

THANKS Vincent! I just tested your 320119-exclude-ancestry branch, on the "davi" testcase above, and
"bzr log -n0 -rtag:mysql-5.1.41..tag:mysql-5.1.42" gave the same results as "bzr missing --include-merges", which is perfect for us.
So to me the proposed solution is very satisfying and would close the case.

>>>>> GuilhemBichot <email address hidden> writes:

    > THANKS Vincent! I just tested your 320119-exclude-ancestry
    > branch, on the "davi" testcase above, and
    > "bzr log -n0 -rtag:mysql-5.1.41..tag:mysql-5.1.42" gave the same

Of course you mean:

   bzr log -n0 -rtag:mysql-5.1.41..tag:mysql-5.1.42 --exclude-coomon-ancestry

 :)

    > results as "bzr missing --include-merges", which is perfect for
    > us.
    > So to me the proposed solution is very satisfying and would close
    > the case.

Cool. The long term plan *may* makes it the default behavior when a
range is specified, but:

1) I'd like a more general feedback first (that's why I created a
   specific option)

2) the log code needs to be deeply reworked and some infrastructure to
   load the graph incrementally is a pre-requisite.

The doc can be fixed independently though.

Hello. I just updated to bzr.dev revno 5204 which has the released fix. I'm testing "bzr log -rX..Y --exclude-common-ancestry" again.
* With MySQL branches, the output doesn't contain X: I used mysql-6.0-codebase and
bzr log -r tag:mysql-6.0.9..tag:mysql-6.0.10 --exclude-common-ancestry ,
and the revision with tag mysql-6.0.9 is not shown.
* In another test, it contains X:
bzr init br1
cd br1
touch foo
bzr add .
bzr commit -m1
echo lkj > foo
bzr commit -m2
echo l > foo
bzr commit -m3
echo lmlll > foo
bzr commit -m4
bzr log -r3..4 --exclude-common-ancestry # shows 3 and 4
* I'm surprised that sometimes X is in and sometimes not.
The definition of this option, per "bzr help log", is
"Display only the revisions that are not part of both ancestries", to me 3 is part of the ancestry of 3, and of 4, so should not be displaid. Is there a minor bug left?

>>>>> GuilhemBichot <email address hidden> writes:

<snip/>

    > bzr log -r3..4 --exclude-common-ancestry # shows 3 and 4
    > * I'm surprised that sometimes X is in and sometimes not.
    > The definition of this option, per "bzr help log", is

    > "Display only the revisions that are not part of both ancestries",
    > to me 3 is part of the ancestry of 3, and of 4, so should not be
    > displaid. Is there a minor bug left?

Argh, yes, probably when revnos are used (not dotted revnos), please
file a new bug, this one is already so long it's not usable anymore.

New bug is https://bugs.launchpad.net/bzr/+bug/575631

Thanks for the new bug.