Code review comment for lp:~guilhem-bichot/bzr/bzr-pull-verbose-shows-tip-before-pull

Revision history for this message
John A Meinel (jameinel) wrote :

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

GuilhemBichot wrote:
> Bonjour Vincent. Yes using append_revisions_only would be great. However, it would require changing the years-old habits of 100 people. They would be problems in the beginning; I would have to dissipate quite some energy to explain, re-explain, fix, and that's not something I can do short-term. Even though it comes back regularly on my long-term plans.
> Yes our devs should know that revnos are unreliable in our case, and some do know. I was more worried about the case where one forgets about this; it's not so easy to remember that the revno which "bzr pull -v" prints at the end of its execution is already out-of-date when it's printed (i.e. is unusable).
> But if there is a UI rule that the revno has to be displayed... case is closed, let's print it :-)

So one option is to look up the revno *after* pull has completed. It
will be a bit slower if the revno ends up being a merge revision, but
you should be able to do:

old_rev_revno = branch.revision_id_to_dotted_revno(original_revision_id)

That was actually the recommendation back when we discussed this in the
past.

And in fact, we would rather show that then the revision_id (we
generally avoid showing revision-ids in the UI where a revno can be
used.) I think it would be great to log it via mutter(). But showing it
to the user should be avoided.

John
=:->

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

iEYEARECAAYFAkseivMACgkQJdeBCYSNAAMstwCghi7LEaaWs8DWdAffgrsCXvTH
/oEAnRqTtExNqpu6x2EGQ+t3MoFmEI0V
=kKt+
-----END PGP SIGNATURE-----

« Back to merge proposal