Comment 1 for bug 215903

Actually, it is potentially a lot trickier than that. The problem is 'mainline' revisions versus 'merged' revisions. Revision numbers are based on mainline. Specifically consider a graph like this:

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

In this case, the revision number for "F" is 3, but there are 6 revisions
total. If you had been at B and done "bzr pull" to get to F, then you only
moved from 2 => 3, but you copied 4 revisions (C, D, E, F).

It is further complicated by graphs like this:

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

In this case, if you are sitting at 'H', you are at revno 6, however for user 2
sitting at 'I' they see only revno 4. Because 'H' is in the ancestry of 'I',
you are allowed to 'bzr pull'. It does change your mainline history, though.

At that point you would change from revno 6 => 4.

We used to show "pulled XX revisions" which indicated the number of steps moved
along the mainline. But because of this graph, that number would sometimes be
negative. (You were at 6, now at 4, that is -2 steps.)

One alternative is to ignore the delta, and just print out the pre-and-post
revision numbers, but you would still see:

Pulled from revision 6 to 4.

(Note that we don't generally encourage this sort of pulling, but there is no
reason to forbid it. Many people like it, because it leads to branch
convergence.)

The only way to have it *always* work is to show the revision_ids. Which would
be possible, but they are ugly for people to generally work with.

There would be a few options if you want to review *before* pulling.

Specifically, you can do:

  bzr merge --preview

Which would show you what would change if you merged, which should be the same
thing as what would change if you pulled. Would that suit your needs? You would
have to do it before the pull, though.