4

I'm offline a lot.

So normally, I use one local clone as a "hub" for features, bugs, etc.

hg clone local-hub bug-123

Works offline. Cool.

Can I use a similar workflow if that project contains remote subrepositories?

Because, if .hgsub says

sub/shared = http://server/hg/shared

hg clone says

abort: error: getaddrinfo failed

Note that once the clone is created (while connected), push and pull will use the path in the subrepo's hgrc (instead of the location in .hgsub). So I can point this to a local clone and everything is cool.

But clone looks at .hgsub (as it's supposed to). So if the "blessed" subrepo is on a server, I can't create new clones offline, even though the files I need are right there.

This is a problem, right?

harpo
  • 41,820
  • 13
  • 96
  • 131

2 Answers2

6

Ideally whomever set up the project uses relative URLs in their .hgsub file like this:

sub/shared = ../shared

and then, of course, actually makes shared a sibling of the main repo. Then as long as you have cloned down the main repo and the subs (as siblings) then everything will work out.

If they've used absolute URLs in their .hgsub file you can work around it using the subpaths section in your .hgrc like this:

[subpaths]
http://server/hg/shared = ../shared

which provides a translation layer in your client.

Ry4an Brase
  • 78,112
  • 7
  • 148
  • 169
  • Hey, thanks! I've read a lot of your writing in my research on this subject... you're a great contributor here. Both options have merits, and I will have to consider which is best for me. Thanks again! – harpo Mar 03 '11 at 05:57
  • ok, there's one sticking point un-hassle-y'd ;-) Is it just me or are sub-repos hard to figure out? – quentin-starin Sep 30 '11 at 23:35
  • @qes they are admittedly hard to figure out. Part of the trouble is that most Mercurial developers don't use them, and those that do are only working on the use cases that affect them. – Ry4an Brase Oct 03 '11 at 02:12
2

The canonical way to use subrepositories is to have X = X paths in the .hgsub file:

sub/shared = sub/shared

That way a clone will structurally look just like the original -- and so you can use the clone to make further (local!) clones.

However, this is not always possible, for example, Bitbucket wont let you create the nested repositories on their server. In that case, the ../X style paths in the .hgsub file is better, and you can use the subpaths configuration section to translate these paths into paths you can use locally.

Martin Geisler
  • 72,968
  • 25
  • 171
  • 229
  • Thanks, Martin. Point for SO; 2 responses, both from experts on the topic. I am definitely interested in the most "canonical" use of subrepos. But doesn't **sub/shared = sub/shared** imply that the subrepo "lives" under the parent, and is thus not really shared? In other words, since .hgsub is actually tracked, shouldn't the right side be the path to the "blessed" subrepo? **../X** seems the most flexible solution. As long as **../X** is a valid location, then clones will look just like the original. – harpo Mar 10 '11 at 18:21
  • @harpo: No, they can still be shared on the server. Please see [my other answer](http://stackoverflow.com/a/7318280/110204) for three different ways of accomplishing this. – Martin Geisler Mar 20 '12 at 13:32