'0' and 'None' as outputs tripped me up. Make the distinction between values
set externally and values computed by calling the decorated function clearer.
Preserve the invariant that if P is a filecached property on X then
P in X.__dict__ => P in X._filecache.
Previously, it was possible for a filecached property to become out of sync
with the filesystem if it was set before getting it first, since the initial
filecacheentry was created in __get__.
Old behaviour:
repo.prop = x
repo.invalidate() # prop has no entry in _filecache, it's not removed
# from __dict__
repo.prop # returns x like before without checking with the
# filesystem
New:
repo.prop = x # an empty entry is created in _filecache
repo.invalidate() # prop is removed from __dict__
repo.prop # recreates prop
We need to make sure that if X is in the filecache then it's also in the
filecache owner's __dict__, otherwise it will go out of sync:
repo.X # first access to X, records stat info in
# filecache and updates __dict__
repo._filecache.clear() # removes X from _filecache but it's still in __dict__
repo.invalidate() # iterates over _filecache and removes entries
# from __dict__, but X isn't in _filecache, so
# it's kept in __dict__
repo.X # X is fetched from __dict__, bypassing the filecache
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 idea is being able to associate a file with a property, and watch
that file stat info for modifications when we decide it's important for it to
be up-to-date. Once it changes, we recreate the object.
On filesystems that can't uniquely identify a file, we always recreate.
As a consequence, localrepo.invalidate() will become much less expensive in the
case where nothing changed on-disk.
