If you create a new bookmark, and then make a commit, the newly created bookmark is still referencing the old changeset. It should have been moved to reference the new commit. It can be reproduced with the following test: diff --git a/tests/test-commandserver.py b/tests/test-commandserver.py --- a/tests/test-commandserver.py +++ b/tests/test-commandserver.py @@ -179,6 +179,16 @@ os.system('hg upd bm1 -q') runcommand(server, ['bookmarks']) +def bookmarks2(server): + # Create new active bookmark 'bm3' + runcommand(server, ['bookmarks', 'bm3']) + f = open('a', 'ab') + f.write('2') + f.close() + runcommand(server, ['commit', '-Amm']) + # bookmarks list bm1 as active, and bm3 still points to the previons changeset. This is bug + runcommand(server, ['bookmarks']) + def tagscache(server): readchannel(server) runcommand(server, ['id', '-t', '-r', '0']) @@ -208,5 +218,6 @@ check(hookoutput) check(outsidechanges) check(bookmarks) + check(bookmarks2) check(tagscache) check(setphase)
I'm not seeing the same here. Can you attach a full patch with the matching .out file such that it fails when you run it? Also, we're talking about 2.1, right? Btw, you're missing a call to readchannel(server) in the beginning of the test.
Yes, this is with 2.1. Attached the the output as I would expect.
and here is the complete test code
OK, after a long and grueling debugging session, I think I know what's happening. We keep a map called _filecache in localrepo. This map, among others contains the contents of .hg/bookmarks.current, **as a string**. So suppose its current contents are 'foo'. Now you run 'hg book bar' through the command server. Then the current bookmarks changes: localrepo._bookmarkcurrent = 'bar' and .hg/bookmarks.current is written. Now we run commit: we call localrepo.invalidate, so the next call to localrepo._bookmarkcurrent checks if _filecache has the most up-to-date contents of .hg/bookmarks.current. It does, so it pulls its OLD contents from the cache without rereading the file, and this is where it breaks. It doesn't see the new value 'bar' that was set before. The assignment to _bookmarkcurrent created a new string and it leaves the old copy in it cache. So basically _filecache breaks when you try to update something in it by creating a brand new object. Incidentally, I found another bug when tracking this one down.
Fixed by http://selenic.com/repo/hg/rev/236bb604dc39 Idan Kamara <idankk86@gmail.com> scmutil: update cached copy when filecached attribute is assigned (issue3263) (please test the fix)
I have tested it and it is working. Thank you.
--- Bug imported by bugzilla@serpentine.com 2012-05-12 09:28 EDT --- This bug was previously known as _bug_ 3263 at http://mercurial.selenic.com/bts/issue3263 Imported an attachment (id=1630) Imported an attachment (id=1631)