revno oddity on lightweight checkout

[John Arbash Meinel]

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

Doug Lee wrote:
| Using Bazaar 1.0 (I hope to upgrade soon but haven't yet) on FreeBSD
| with Python 2.4.3.  I made a lightweight checkout of a rather large
| branch in a shared repo (over 6,000 files/folders) and made a commit
| or two.  Then I made a mistake:  I got two commits in two separate
| shells but using the same lightweight checkout tree going at once.
| The big one politely waited for the little one to let go the lock, and
| then it went through; but it ended by saying, "Committed revision 1."
| It should have been more like revision 3.
|
| Now as I commit, the following anomalies persist:
|
| 1.  New commits report revision numbers that are three too low, but
| `bzr log' reports all the correct revisions.
|
| 2.  `bzr revno' reports revision 3 but `bzr update' reports "Tree is
| up to date at revision 6."
|
| 3.  `bzr revno' from within the actual shared repo's branch folder
| reports the same oddly low revno as in the lightweight checkout.  `bzr
| log' there reports the expected revisions.
|
| I think my repo is fine as far as containing everything it should and
| letting me get it back, but I want to (1) verify this and (2) find out
| if I can somehow make bzr figure out the right revno from now on.
|
| Btw, I don't know if my parallel-commit incident really matters here,
| but it seemed odd enough to be worth pointing out.
|
|

This does seem odd. I'm curious if you just do "bzr pull --overwrite" if it will
get you back in sync.

I certainly would think that the second commit would grab the correct revision
number after it finally acquired the lock. Have you been able to reproduce this
at all?

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

iD8DBQFH1YCyJdeBCYSNAAMRAjbGAJ9Wa2JMHmcWpcHCMZXpR2oqlbb6pQCfba8+
dgFBDplA4DuzwBB7JqkJrTI=
=ZYrw
-----END PGP SIGNATURE-----