revno oddity on lightweight checkout

[Doug Lee]

On Mon, Mar 10, 2008 at 01:40:50PM -0500, John Arbash Meinel wrote:
> 
> 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?

I didn't mess with this issue for a long time until this week, but I
now have a bit more info:

The branch/lastrevision file was wrong in that the revno was three too
low, though the ID was the latest revision's ID.  This means that
counting backward from the recorded revno would hit the first ID too
soon.  `bzr log' without arguments actually lists all revs with
correct numbers, but things like `bzr log -r-1' start three too far
back in numbers (and, I think, actual rev).  `bzr push' pushed three
too few revs but ended up at the right place (current code).  I
finally edited the lastrevision file and got correct results locally,
but I had to rebuild the pushed repo to get them to match.

I'm not sure, but I imagine you could reproduce this whole scenario by
manually lowering the revno in that file and doing commits etc.


-- 
Doug Lee                 dgl at dlee.org        
SSB BART Group           doug.lee at ssbbartgroup.com   http://www.ssbbartgroup.com
What is most worth paying for, you buy with the life you live.
(11/10/07)