Mercurial Mercurial > mercurial / changeset
summary | shortlog | changelog | graph | tags | bookmarks | branches | files | changeset | raw | help
Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
localrepo: document and test bug around opening shared repos
authorGregory Szorc <gregory.szorc@gmail.com>
Wed, 12 Sep 2018 13:10:45 -0700
changeset 39696 9de1a1c83cd7
parent 39695 cb2dcfa5cade
child 39697 98ca9078807a
localrepo: document and test bug around opening shared repos As part of refactoring this code, I realized that we don't validate the requirements of a shared repository. This commit documents that next to the requirements validation code and adds a test demonstrating the buggy behavior. I'm not sure if I'll fix this. But it is definitely a bug that users could encounter, as LFS, narrow, and potentially other extensions dynamically add requirements on first use. One part of this I'm not sure about is how to handle loading the .hg/hgrc of the shared repo. We need to do that in order to load extensions. But we don't want that repo's hgrc to overwrite the current repo's. Differential Revision: https://phab.mercurial-scm.org/D4572
mercurial/localrepo.py file | annotate | diff | comparison | revisions
tests/test-share.t file | annotate | diff | comparison | revisions 
--- a/mercurial/localrepo.py	Wed Sep 12 15:03:17 2018 -0700
+++ b/mercurial/localrepo.py	Wed Sep 12 13:10:45 2018 -0700
@@ -438,6 +438,19 @@
     # Then we validate that the known set is reasonable to use together.
     ensurerequirementscompatible(ui, requirements)
 
+    # TODO there are unhandled edge cases related to opening repositories with
+    # shared storage. If storage is shared, we should also test for requirements
+    # compatibility in the pointed-to repo. This entails loading the .hg/hgrc in
+    # that repo, as that repo may load extensions needed to open it. This is a
+    # bit complicated because we don't want the other hgrc to overwrite settings
+    # in this hgrc.
+    #
+    # This bug is somewhat mitigated by the fact that we copy the .hg/requires
+    # file when sharing repos. But if a requirement is added after the share is
+    # performed, thereby introducing a new requirement for the opener, we may
+    # will not see that and could encounter a run-time error interacting with
+    # that shared store since it has an unknown-to-us requirement.
+
     # At this point, we know we should be capable of opening the repository.
     # Now get on with doing that.
 
--- a/tests/test-share.t	Wed Sep 12 15:03:17 2018 -0700
+++ b/tests/test-share.t	Wed Sep 12 13:10:45 2018 -0700
@@ -439,6 +439,29 @@
 
   $ rm -r thatdir
 
+Demonstrate buggy behavior around requirements validation
+See comment in localrepo.py:makelocalrepository() for more.
+
+  $ hg init sharenewrequires
+  $ hg share sharenewrequires shareoldrequires
+  updating working directory
+  0 files updated, 0 files merged, 0 files removed, 0 files unresolved
+
+  $ cat >> sharenewrequires/.hg/requires << EOF
+  > missing-requirement
+  > EOF
+
+We cannot open the repo with the unknown requirement
+
+  $ hg -R sharenewrequires status
+  abort: repository requires features unknown to this Mercurial: missing-requirement!
+  (see https://mercurial-scm.org/wiki/MissingRequirement for more information)
+  [255]
+
+BUG: we don't get the same error when opening the shared repo pointing to it
+
+  $ hg -R shareoldrequires status
+
 Explicitly kill daemons to let the test exit on Windows
 
   $ killdaemons.py
mercurial