Bookmarks are repository data, not working directory data. Only the current
bookmark is working directory data.
Some lock shuffling is required to avoid lockout between the initial mock lock
and locking of the localrepo instance that is created after copying.
This makes bookmarks.update() and bookmarks.updatecurrentbookmark() return
True or False to indicate whether the bookmark was updated or not. This allows
callers to e.g. abort if the update failed.
The usual contract is that close() makes your writes permanent, so
atomictempfile's use of close() to *discard* writes (and rename() to
keep them) is rather unexpected. Thus, change it so close() makes
things permanent and add a new discard() method to throw them away.
discard() is only used internally, in __del__(), to ensure that writes
are discarded when an atomictempfile object goes out of scope.
I audited mercurial.*, hgext.*, and ~80 third-party extensions, and
found no one using the existing semantics of close() to discard
writes, so this should be safe.
The current bookmark is stored in bookmark.current, supposingly in UTF-8.
But the call to encoding.fromlocal() is missing, therefore Hg is not able
to recognize the current bookmark in the case that bookmark uses
characters of which the bit stream is different between local encoding
and UTF-8.
For example, the Chinese version of Windows cmd uses gbk(cp936), not UTF-8.
Therefore I won't be able to make a Chinese bookmark current.
By wrapping mark in a encoding.fromlocal() call, the problem is solved.
Before this patch undo.bookmarks was created on bookmarks write and
not with other transaction-related files. There were two issues: first
is that if you have changed bookmarks few times after a transaction
happened, rollback will give you a state which can point to
non-existing revision. Second is that if you have not changed
bookmarks after a transaction, rollback will touch your state anyway.
This change also adds `localrepo._writejournal` method, which can be
used by other extensions to save their transaction-related backup in
right time.
After a rollback, the current bookmark might be absent from the bookmarks
file. In that case we discard it instead of displaying a traceback during
commit.
A bookmark can only move to a descendant on commit, pull or
unbundle. Bookmarks cannot jump between heads anymore. This fixese
issue 1502.
We explicitly use new.node(), to emphasise that we are updating the
current bookmark to the new node.
We restrict : to 1. make it easer to convert bookmarks to git branches,
2. use : later for a syntax to push a local bookmark to a remote bookmark
of a different name. \0, \n, \r are fobbidden they are used to separate
bookmarks in the bookmark file.
This change breaks backward compatbility as ':' was an allowed character in
previous versions.
These leaks may occur in environments that don't employ a reference
counting GC, i.e. PyPy.
This implies:
- changing opener(...).read() calls to opener.read(...)
- changing opener(...).write() calls to opener.write(...)
- changing open(...).read(...) to util.readfile(...)
- changing open(...).write(...) to util.writefile(...)
We check if the current bookmark is set to the first parent of the
dirstate. Is this the case we move the bookmark to most recent revision
on the current branch (where hg update will update you to).
setcurrent refuses to set a new current bookmark if the current bookmark
points to the current dirstate. This restriction is not needed. A current
bookmark can point to a different bookmark.
We explicitly want to update bookmarks from a remote. This will avoid
duplicate calls to listkeys if we clone (which calls pull) and keep
bookmark related code together.