The fix for https://bz.mercurial-scm.org/show_bug.cgi?id=5675, which shares subrepositories instead of cloning them when the parent is also shared, made it impossible to use the ShareExtension when the subrepository is remote. Entries in .hgsub may specify an absolute URL, not necessarily on the same server as the parent repository. Attempting to share such a repository results in $ hg up --clean --rev 2017.1 sharing subrepo native/libecw from https://... abort: can only share local repositories (in subrepository "native/libecw") Although the Subrepository documentation recommends mirroring repositories instead of using absolute URLs, that is often not feasible and cumbersome in production environments. Sharing will also not work if the subrepository is specified as a relative path within the parent and the base clone is at a revision that doesn't contain the subrepository (the null revision for example). While I do understand the reasoning behind the fix, I feel you should be able to turn it off or specify a fallback behavior for non-shareable subrepositories.
Perhaps the source repository to be shared should be resolved relative to the root shared repository.
Indeed, if some clone at /path/to/clone with .hgsub entry "libfoo = https://server/hg/foo" is shared, libfoo in the sharing repository should share from /path/to/clone/libfoo and not try to use the URL. This does require the base clone to be at a revision containing the subrepository. If it's at revision null (hg clone -U), which is often the case in caching setups, there is nothing to share from.
I haven’t looked at the code yet, but I wonder if the source doesn’t exist (because of clone -U), if we should init an empty repo there, and share that to keep from using the old clone behavior. Obviously, this could entail a pull after the share. Presumably if you are sharing, you’re not doing so from a read only location. The default path wouldn’t be set, but I think the parent generally overrides that anyway.
Bug marked urgent for 10 days, bumping
This doesn't play nice with share pooling either: $ hg clone https://server.org/repo repo (sharing from existing pooled repository 3994fc2378125e1c9d1f9bdd90ea8720db4cbb23) searching for changes no changes found updating working directory sharing subrepo include from https://server.org/repo/subrepo abort: can only share local repositories (in subrepository "subrepo")
So maybe we need to disable the feature (or make it config gated) for stable?
I’ll take a hard look at this today or tomorrow. I don’t really like the config option, because it breaks the share source in some cases. Last I heard, the next release is delayed a few days for the sprint, so I think there’s still some time to try to sort this out.
(In reply to Erik De Weerdt from comment #0) I think I have a trivial fix for this- hgsubrepo._get() needs to add this check to the conditional that the parent is shared: `hg.islocal(srcurl)`. Right now I'm trying to figure out a weird test instability that seems to predate this change, but I'll probably submit this tomorrow either way. > Sharing will also not work if the subrepository is specified as a relative > path within the parent and the base clone is at a revision that doesn't > contain the subrepository (the null revision for example). I can't tell if you mean this is another problem, or if this is a reason for using absolute subrepo references. Clone won't work in this case either.
Fixed by https://mercurial-scm.org/repo/hg/rev/eed02e192770 Matt Harbison <matt_harbison@yahoo.com> subrepo: don't attempt to share remote sources (issue5793) Untangling _abssource() to resolve the new subrepo relative to the shared parent's share path, and then either sharing from there (if it exists), or cloning to that location and then sharing, is probably more than should be attempted on stable. Absolute subrepo references are discouraged, so for now, this resumes the behavior prior to 68e0bcb90357 of cloning the absolute subrepo locally. (please test the fix)
Bug was set to TESTING for 7 days, resolving