Nested Subrepos non-recursive/deferred cloning

[Ken Frederickson]

Hello,

When using subrepos, I frequently get in a situation where nested subrepos
result in multiple copies of the same repo. This can cause several
headaches, like a hit on sync time, confusion which copy of the redundant
repo I'm co-developing, etc. Additionally, it's troubling that cloning of
the parent repo fails if the clone of the subrepo fails, which could easily
happen if the URL of the subrepo has been altered (i.e. server migration).

My solution is to write a custom extension that largely mimics the
functionality of subrepos, but does not automatically recursively clone
subrepos. Instead, I would make a command that I could execute at each repo
level that would pull one or all of its subrepos. My question is: have some
of these issues already been considered or partially addressed with more
recent subrepo work? Should I contribute to subrepo or should I stick with
an independent extension?

I understand the recommended way
<https://www.mercurial-scm.org/wiki/Subrepository> of avoiding redundant
copies of repos is to use a super repo ("shell repo"). Unfortunately, this
comes with a number of undesirable side effects. It doesn't allow my
company's strict policy that every check-in pass a smoke test. If a repo
does not maintain its own subrepos but instead relies on a shell repo, the
repo can't be built and smoked in an atomic check-in operation. It requires
a second commit to shell repo. The other side effect is I necessarily need
to create a companion shell repo for everything I want my CI server to
test. Then there are workflow issues if the repo is a subrepo of an app
shell: somehow I need to commit the repo, the app shell, and the dedicated
companion shell in an atomic way.

I've tried the Guest Repo and Repoman extensions without success. Is a new
run at a subrepo alternative of interest to others?

Thanks,
Ken
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20161023/ac060974/attachment.html>