Pushing relative subrepos

[Matt Mackall]

On Thu, 2010-11-18 at 12:20 +0100, Georg Zetzsche wrote:
> Am 17.11.2010 21:32, schrieb Matt Mackall:
> >> As far as I can see, "hg push" should "hg init" a subfolder in the
> >> target repo before pushing the subrepo in this case.
> >>
> >> Is this a bug?
> > 
> > No. It's always been the user's job to initialize repositories before
> > pushing to them.
> 
> Keeping this behaviour would mean that every time someone adds a subrepo
> (which I would consider part of the parent repo, if it has a relative
> location), they have to ask an administrator to initialize a subrepo with
> the corresponding name, although they have the permission to push. Is this
> really the intended workflow?

No, actually, the intended workflow in a distributed system is for
everyone to have admin rights on their own private publishing repos, and
to never push to shared repositories. But people still recovering from
CVS seem to like having everyone still race to push to a single shared
repository. That's allowed, but it's not optimal.

> On the other hand, when you pull -u from a repo that has a new subrepo,
> a new folder is readily initialized. Isn't this somewhat asymmetrical?

First, let's back up. Pull never touches the working directory, and
doesn't visit subrepos. That's the job of update, which is a very
distinct operation from pull. Sneaking it into your argument about push
vs pull with the -u convenience flag is cheating.

Yes, push and pull are definitely asymmetrical. This should be no
surprise to anyone who's used a rope. For starter, pull intrinsically
has permissions on the destination. Second, any number of sources can
attempt to push to a given destination simultaneously, but pull will
only ever pull one source to a destination at a time - no races.

-- 
Mathematics is the supreme nostalgia of our time.