Bug 5793 - Fix for #5675 made it impossible to share repositories containing external subrepositories
Summary: Fix for #5675 made it impossible to share repositories containing external su...
Status: RESOLVED FIXED
Alias: None
Product: Mercurial
Classification: Unclassified
Component: Mercurial (show other bugs)
Version: 4.4
Hardware: All All
: urgent bug
Assignee: Bugzilla
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2018-02-16 04:46 UTC by Erik De Weerdt
Modified: 2018-03-12 00:00 UTC (History)
3 users (show)

See Also:
Python Version: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Erik De Weerdt 2018-02-16 04:46 UTC
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.
Comment 1 Yuya Nishihara 2018-02-16 07:37 UTC
Perhaps the source repository to be shared should be resolved relative
to the root shared repository.
Comment 2 Erik De Weerdt 2018-02-16 08:04 UTC
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.
Comment 3 Matt Harbison 2018-02-16 20:31 UTC
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.
Comment 4 Bugzilla 2018-02-27 00:00 UTC
Bug marked urgent for 10 days, bumping
Comment 5 Matt Harbison 2018-02-27 10:21 UTC
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")
Comment 6 Yuya Nishihara 2018-02-27 10:48 UTC
So maybe we need to disable the feature (or make it config gated) for stable?
Comment 7 Matt Harbison 2018-02-27 11:18 UTC
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.
Comment 8 Matt Harbison 2018-03-01 23:38 UTC
(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.
Comment 9 HG Bot 2018-03-04 10:45 UTC
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)
Comment 10 Bugzilla 2018-03-12 00:00 UTC
Bug was set to TESTING for 7 days, resolving