revno oddity on lightweight checkout
John Arbash Meinel
john at arbash-meinel.com
Mon Mar 10 18:40:50 GMT 2008
-----BEGIN PGP SIGNED MESSAGE-----
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the bazaar