tracked-key: remove the dual write and rename to tracked-hint
The dual-write approach was mostly useless. As explained in the previous version
of the help, the key had to be read twice before we could cache a value.
However this "read twice" limitation actually also apply to any usage of the
key. If some operation wants to rely of the "same value == same tracked set"
property it would need to read the value before, and after running that
operation (or at least, after, in all cases). So it cannot be sure the operation
it did is "valid" until checking the key after the operation. As a resultat such
operation can only be read-only or rollbackable.
This reduce the utility of the "same value == same tracked set" a lot.
So it seems simpler to drop the double write and to update the documentation to
highlight that this file does not garantee race-free operation. As a result the
"key" is demoted to a "hint".
Documentation is updated accordingly.
Differential Revision: https://phab.mercurial-scm.org/D12201
tracked-file: rename the format option to use `use-`
This is more consistent with the other options.
Differential Revision: https://phab.mercurial-scm.org/D12200
tracked-key: update the requirement value
We renamed the config option but we forgot to change the actual value…
Differential Revision: https://phab.mercurial-scm.org/D12199
tracked-key: make it possible to upgrade to and downgrade from the feature
This seems rather important if we want people to start using it.
Differential Revision: https://phab.mercurial-scm.org/D12198
obsolete: don't use os.stat in repo.obsstore.__nonzero__ if it's static HTTP
If a repo is accessed via static HTTP, then we obviously can't use os.stat() to
just peek at the file size. Let's download the entire file to check its size.
Yes, this feels wasteful, but:
1. If we're cloning or pulling a repo from a static HTTP server, we need the
contents of the obsstore anyway.
2. Implementing statichttpvfs.stat() that uses HEAD will result in one more
request to a static-only HTTP server, which is already slow. Also parsing a
response to a HEAD request to construct os.stat_result is pretty hacky.
There's also a question of the remote server properly supporting HEAD method
and reporting at least file size.
3. Implementing statichttpvfs.stat() that uses GET is pretty much the same
thing as we do here, except we can't even cache the response easily, unlike
simply accessing obsstore._data, which is @propertycache'd.
Importing statichttprepo locally to avoid circular import.
See also:
4507bc001365 and commit message of
f8f2ecdde4b5.
Differential Revision: https://phab.mercurial-scm.org/D12195