atom feed10 messages in com.selenic.mercurialRe: Pushing relative subrepos
FromSent OnAttachments
Georg ZetzscheNov 17, 2010 10:35 am 
Matt MackallNov 17, 2010 12:32 pm 
Zoom.QuietNov 17, 2010 5:12 pm 
Georg ZetzscheNov 18, 2010 3:20 am 
Georg ZetzscheNov 18, 2010 4:07 am 
Matt MackallNov 18, 2010 9:27 am 
Georg ZetzscheNov 18, 2010 9:47 am 
Martin GeislerNov 18, 2010 9:51 am 
Georg ZetzscheNov 18, 2010 10:03 am 
David I.Nov 19, 2010 11:38 am 
Subject:Re: Pushing relative subrepos
From:Matt Mackall (
Date:Nov 18, 2010 9:27:16 am

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.