Read Only Subrepos?

[Matt Mackall]

[cc:ed back to list]

On Wed, 2010-08-11 at 22:45 -0500, Steve Borho wrote:
> On Wed, Aug 11, 2010 at 7:35 PM, Matt Mackall <mpm at selenic.com> wrote:
> > On Wed, 2010-08-11 at 11:12 -0400, Ryan Wilcox wrote:
> >> On Tue, Aug 10, 2010 at 3:28 AM, Dirkjan Ochtman <dirkjan at ochtman.nl> wrote:
> >> > On Sat, Aug 7, 2010 at 15:57, Ryan Wilcox <ryanwilcox at gmail.com> wrote:
> >> >> Is there  way to configure Mercurial to not try to push those subrepos
> >> >> by default?
> >> >
> >> > We've talked about supporting vendor/externals (invariant: subrepos
> >> > are considered read+pull-only by the main repo) better as subrepos
> >> > using a setting in .hgsub, but it hasn't been done yet. Supposedly
> >> > that would help this use case, as well.
> >> >
> >>
> >> Would patches implementing read only subrepos be accepted, or is this
> >> (say) not the direction you want to take?
> >
> > It's reasonable, but it's the wrong answer for this particular issue.
> >
> > An empty push to a pullable repo should always work, regardless of
> > whether you have permission to push or not. The first part of the push,
> > discovery, is allowed for both push and pull, and the second part
> > (actually sending a bundle) is skipped if there's nothing to send.
> >
> > So unmodified subrepos shouldn't be causing a problem.
> 
> I can attest this is still very much an issue.  I quit using subrepos
> for my Windows installer build setup after just a week because every
> push took minutes even though I was only ever making commits to the
> root repository.   And having just one remote URL being unresponsive
> made the entire push fail, even though you have no outgoing changes
> for that URL.

If we add read-only repos, we'll still have done nothing to address the
as-yet -undiagnosed- bug that started this thread. Let's focus on that
diagnosis first.

-- 
Mathematics is the supreme nostalgia of our time.