'bzr pull' should report number of new revisions retrieved

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.

First off, thanks for the extremely detailed response :)

I understand the complications you put forward, and one approach I can think of, off the top of my head, is count how many new revision-ids I'm bringing in.

That would address what I was expecting.

What do you think of that?

That doesn't seem to address what Jamu wanted.

Specifically, it seemed he wanted to be able to do:

bzr pull
X revisions pulled

bzr diff -r -X

That generally won't work if the branch changes mainlines.

Further, if you include all revisions, it also won't work if there are any merges in what you are pulling.

I can understand displaying the number of new revisions (revisions in the ancestry of the new tip, that were not in the old tip). However, it doesn't necessarily fit the use case that was requested.

As for why we don't do it.... because we don't have an accurate and efficient function (yet) to compute it. 'graph.find_differences()' is approximately correct and efficient, but is not 100% accurate with all possible graphs.

> 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.

Another possibility would be to show revnos relative to the current
[new] history.

---
Now on revision 12345.
Previous head was 12307.1.6.
---

My use case is that I want to pull, and then log -r-20.. (or
whatever). Since it's pretty rare that I need to worry about a moving
mainline, I'm in the habit of revno ; pull ; [mental arithmetic] ; log
-r-foo.. which is somewhat annoying. And then when mainline DOES
move...

(pull -v != log)

--
Matthew Fuller
<email address hidden>

Thanks for the awesome explanation John. I'm quite happy to
continue with my current workflow. It seemed like a simple
improvement at first sight. :)

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

fullermd wrote:

> My use case is that I want to pull, and then log -r-20.. (or
> whatever). Since it's pretty rare that I need to worry about a moving
> mainline, I'm in the habit of revno ; pull ; [mental arithmetic] ; log
> -r-foo.. which is somewhat annoying. And then when mainline DOES
> move...
>
> (pull -v != log)

That seems a rather terse rationale for not using the functionality that
was intended to address this use case.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFICqxn0F+nu1YWqI0RAtYcAJ94RwS1qX00LNrKd0iUjGEo0n/OQgCeOPb0
mCM1+nDq86ofunfOL+wA2z4=
=koz8
-----END PGP SIGNATURE-----

Removing myself as I don't see a clear way to implement this :)

Actually, looking up the revnos in terms of the current tip would be reasonable. Aside from the performance scaling issues of dotted revnos... To be efficient, you probably need to do a little bit of iter_history to see if it is in the recent mainline, and then switch to 'get_revno_for_revision_id()' which will build the dotted revno map.

Could a workaround be to instead report the previous tip?

   All changes applied successfully.
   Was on revision 17562.
   Now on revision 17563.

(Perhaps even better would be something like:

   Changed from revision 17562..17563.

for easier copying and pasting, though I don't it would work nicely with foreign revnos.)

=== modified file 'bzrlib/branch.py'
--- bzrlib/branch.py 2011-08-19 22:34:02 +0000
+++ bzrlib/branch.py 2011-08-25 20:06:15 +0000
@@ -3063,7 +3063,8 @@
             if self.old_revid == self.new_revid:
                 to_file.write('No revisions to pull.\n')
             else:
- to_file.write('Now on revision %d.\n' % self.new_revno)
+ to_file.write('Was on revision %d.\nNow on revision %d.\n' %
+ (self.old_revno, self.new_revno))
         self._show_tag_conficts(to_file)

On 08/25/2011 10:10 PM, Brian de Alwis wrote:
> Could a workaround be to instead report the previous tip?
>
> All changes applied successfully.
> Was on revision 17562.
> Now on revision 17563.
>
> (Perhaps even better would be something like:
>
> Changed from revision 17562..17563.
>
> for easier copying and pasting, though I don't it would work nicely with
> foreign revnos.)
>
> === modified file 'bzrlib/branch.py'
> --- bzrlib/branch.py 2011-08-19 22:34:02 +0000
> +++ bzrlib/branch.py 2011-08-25 20:06:15 +0000
> @@ -3063,7 +3063,8 @@
> if self.old_revid == self.new_revid:
> to_file.write('No revisions to pull.\n')
> else:
> - to_file.write('Now on revision %d.\n' % self.new_revno)
> + to_file.write('Was on revision %d.\nNow on revision %d.\n' %
> + (self.old_revno, self.new_revno))
> self._show_tag_conficts(to_file)
>
Yeah, that makes sense. I don't think it really needs two lines though.
Perhaps "Now on revision 17563 (was: 17562).".

It might be confusing if the user tries to see what has changed by
running "bzr log-r17562..17563". That won't necessarily display the
right changes.

Cheers,

Jelmer

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

On 8/30/2011 2:51 AM, Jelmer Vernooij wrote:
> On 08/25/2011 10:10 PM, Brian de Alwis wrote:
>> Could a workaround be to instead report the previous tip?
>>
>> All changes applied successfully. Was on revision 17562. Now on
>> revision 17563.
>>
>> (Perhaps even better would be something like:
>>
>> Changed from revision 17562..17563.
>>
>> for easier copying and pasting, though I don't it would work
>> nicely with foreign revnos.)
>>

The problem is that you can switch branch ancestries with pull, so the
old number may not be accurate. Probably you'd want to do:

old_revno_from_new = branch.revision_id_to_dotted_revno(old_revid)

That way after the pull, they could always 'bzr log -r X' that we display.

Note that could also return "None" or exception if you use 'bzr pull
- --overwrite', etc.

John
=:->

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

iEYEARECAAYFAk5cyRoACgkQJdeBCYSNAAMWNQCfQjkGsyEsq+H3QBXducgd8vp1
SCQAoJmLsLP+wS4IqU5RmwNuEKzZKcA0
=No//
-----END PGP SIGNATURE-----