lfs: add repository feature denoting the use of LFS Whether LFS is enabled seems like a useful feature to expose. This will also facilitate some future work around LFS feature compatibility. Differential Revision: https://phab.mercurial-scm.org/D4710

localrepo: define "features" on repository instances (API) There are a handful of attributes/methods on repository instances that describe the behavior of the repository. Furthermore, there is an unbound set of repository descriptors that we may wish to expose. For example, an extension may wish to add a descriptor and have monkeypatched functions look for the presence of an attribute before taking actions. This commit introduces a "features" mechanism to allow repositories to self-advertise an arbitrary set of strings that describe repository behavior or capabilities. We implement basic support for advertising a few features to give an idea of what I want to use this for. Differential Revision: https://phab.mercurial-scm.org/D4709

localrepo: support writing shared file (API) Now that we can create a shared repository via creation options, we can handle other special actions related to share at repo creation time as well. One of the things we do after creating a shared repository is write out a .hg/shared file containing the list of additional things to share. Of which only "bookmarks" is supported. We add a creation option to hold the set of additional items to share. If items are defined, we write out the .hg/shared file at repo creation time. As part of this, we no longer hold the repo lock when writing the file. I'm pretty sure we don't care about the tiny race condition window. I'm also pretty sure the reason we used the lock was because the vfs auditor on the repo instance complained otherwise. Since the repo creation code doesn't have an audited vfs, we don't need to appease it. Because we no longer need to tell the post share hook what items are shared, the "bookmarks" argument to that function has been dropped, incurring an API change. Differential Revision: https://phab.mercurial-scm.org/D4708

localrepo: support shared repo creation Previously, hg.share() had its own logic for creating a new repository on the filesystem. With the recent introduction of the createopts dict for passing options to influence repository creation, it is now possible to consolidate the repo creation code for both the normal and shared use cases. This commit teaches the repo creation code in localrepo to recognize when we're creating a shared repo and to act appropriately. Meaningful behavior should be identical. However, there are a few subtle changes: * The .hg/requires file is written out in sorted order (rather than having share-related requirements appended at end). * The .hg directory is created with notindexed=True when a shared repo is being created. Differential Revision: https://phab.mercurial-scm.org/D4707

localrepo: validate directories before creating any There is no meaningful change in behavior because wdir would already exist in the case where we raised RepoError. But I think the code is easier to read if we do all validation first then take actions with side-effects. Differential Revision: https://phab.mercurial-scm.org/D4706

localrepo: add missing join() Differential Revision: https://phab.mercurial-scm.org/D4705

revlog: use proper version comparison during verify Verify appears to want to compare the changelog's revlog version number with the version number of filelogs and error if they are different. But what it was actually doing was comparing the full 32-bit header integer, which contains 2 shorts: 1 for the revlog version number and 1 for feature flags. This commit tweaks the verification code so it only looks at the version number component of the header and emits a warning if they differ. The new code is more robust because it accounts for future revlog version numbers without them needing to be special cased. Differential Revision: https://phab.mercurial-scm.org/D4704

filelog: stop proxying checksize() (API) This was only used by verify code. And the check using it is now implemented as part of verifyintegrity(). The method is unused and is revlog-centric, which means it isn't appropriate for the file storage interface. So remove it. Differential Revision: https://phab.mercurial-scm.org/D4703

filelog: remove version attribute (API) This was only used by verify code. The check it was used for is now implemented as part of the verifyintegrity() implementation. The attribute is now unused, is revlog-specific, and isn't appropriate to be exposing on the file storage interface. So drop it. Differential Revision: https://phab.mercurial-scm.org/D4702

verify: start to abstract file verification Currently, the file storage interface has a handful of attributes that are exclusively or near-exclusively used by repo verification code. In order to support verification on non-revlog/alternate storage backends, we'll need to abstract verification so it can be performed in a storage-agnostic way. This commit starts that process. We establish a new verifyintegrity() method on revlogs and expose it to the file storage interface. Most of verify.verifier.checklog() has been ported to this new method. We need a way to represent verification problems. So we invent an interface to represent a verification problem, invent a revlog type to implement that interface, and use it. The arguments to verifyintegrity() will almost certainly change in the future, once more functionality is ported from the verify code. And the "revlogv1" version check is very hacky. (The code in verify is actually buggy because it is comparing the full 32-bit header integer instead of just the revlog version short. I'll likely fix this in a subsequent commit.) Differential Revision: https://phab.mercurial-scm.org/D4701