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:
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/
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
GuilhemBichot wrote: 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.
> Bonjour Vincent. Yes using append_
> 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----- enigmail. mozdev. org/
eivMACgkQJdeBCY SNAAMstwCghi7LE aaWs8DWdAffgrsC XvTH 6x2EGQ+ t3MoFmEI0V
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://
iEYEARECAAYFAks
/oEAnRqTtExNqpu
=kKt+
-----END PGP SIGNATURE-----