util: make sortdict.keys() return a copy
dict.keys() is documented to return a copy, so it's surprising that
sortdict.keys() did not. I noticed this because we have an extension
that calls readlocaltags(). That method tries to remove any tags that
point to non-existent revisions (most likely stripped). However, since
it's unintentionally working on the instance it's modifying, it
sometimes fails to remove tags when there are multiple bad tags in a
row. This was not caught because localrepo.tags() does an additional
layer of filtering.
sortdict is also used in other places, but I have not checked whether
its keys() and/or __delitem__() methods are used there.
$ hg init test
$ cd test
$ echo foo>foo
$ hg addremove
adding foo
$ hg commit -m "1"
$ hg verify
checking changesets
checking manifests
crosschecking files in changesets and manifests
checking files
1 files, 1 changesets, 1 total revisions
$ hg clone . ../branch
updating to branch default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cd ../branch
$ hg co
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ echo bar>>foo
$ hg commit -m "2"
$ cd ../test
$ hg pull ../branch
pulling from ../branch
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
(run 'hg update' to get a working copy)
$ hg verify
checking changesets
checking manifests
crosschecking files in changesets and manifests
checking files
1 files, 2 changesets, 2 total revisions
$ hg co
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cat foo
foo
bar
$ hg manifest --debug
6f4310b00b9a147241b071a60c28a650827fb03d 644 foo
update to rev 0 with a date
$ hg upd -d foo 0
abort: you can't specify a revision and a date
[255]
$ cd ..