Path expansion in the .hgsub file

Martin Geisler mg at lazybytes.net
Sat Jul 17 17:16:39 UTC 2010


Didly Bom <didlybom at gmail.com> writes:

Hi Didly

> I am really interested in this issue, as we use subrepos quite
> extensively where I work. I went through the original thread first so
> I think that I know pretty much what you guys are trying to do, but
> still I'd like to make sure that understand the proposed solution.

Great that you come with input... I have not used subrepositories in a
real project myself.

> If I understood you guys properly, the idea is to be able to set a set
> of "alternative mappings" for certain prefixes that you can use when
> defining the subrepository mappings. Is that right?

Well, Matt suggested that. I'm not sure I'm implementing this, though.
The simple system for remapping URLs in the .hgsub file seems to be
enough for people.

> It seems that you'll be able to add new mappings that will be tried in
> order (hopefully from newest to oldest) until one is found to work. As
> a last resort hg will try to use the actual url (or folder name) set
> in the .hgsub file as is. Is that correct?

Yeah, that is also how I understood it.

> I have two questions:
>
> 1. How will this work with relative subrepository mappings? For
> example, if I had the following .hgsub file:
>
>   my_subrepo = ../../components/component1
>
> In which I try to map a subrepo folder named my_subrepo to a
> repository that is two folders up then 2 folders down relative to the
> source repository, will that still work? Will you still be able to
> create a mapping in that situation?
>
> I guess that what I am asking is whether the new behaviour will work
> equally well with all types of sources (http, ssh, local addresses and
> absolute and relative paths)

The patch I posted yesterday or the day before just rewrote prefixes of
the URLs. So you could do

  [paths] # or [sub-paths] or whatever the section name should be
  ../../components = http://my-remote-server

and the .hgsub line above would be understood as

  my_subrepo = http://my-remote-server/component1

The remapping is completely general, i.e., it is very dump and simple
and just replaces a prefix in the URL with something else :-)

> 2. Will you be somehow able to distribute new mappings from the
> central repository, while still letting the user override the
> "suggested" mappings with its own (by means of its .hg/hgrc file I
> assume)?
>
> Also, one thing that I've always found a bit weird is the fact that
> the .hgsub mappings seem to override the default mapping that is set
> on the hgrc file of each subrepository. I think that this is quite
> confusing and should be addressed. For instance, if you update the
> parent repo you may pull new revisions for the subrepos using as a
> source whatever is set on the .hgsub file. But if you enter the
> subrepository and do a regular pull you may end up pulling from a
> different source, couldn't you?

Yeah, that is correct -- when you 'hg update' the .hgsub file tells
Mercurial where to clone/pull from and the .hgsubstate file tells it
which revision to clone/pull.

The .hg/hgrc files in the subrepositories are not used, though a normal
'hg pull' inside a subrepo will of course use it.

> Perhaps there could (or there is already?) be a way to tell tortoisehg
> to use the default mapping of the subrepository itself, or even any
> other non default mapping set in the subrepository hgrc file?

When a repository containing a subrepository is cloned the first time,
the .hg/hgrc file for the subrepository is written so that the new
subrepo will pull from the old subrepo.

> Finally, going through the original discussion it seems to me that
> there are two opposing behaviors that people want to achieve via the
> .hgsub mappings. On one side people want to select the mappings in a
> way that is independent on the selected master repository revision. On
> the other people want to be able to exactly go back to a previous
> configuration, including the subrepository mappings. The current
> mercurial behavior lets you achieve the latter, but not the former. I
> think that any solution that does not address both will leave some
> people dissatisfied.

Right. The subrepo feature promises you that you can operate on a tree
of repositories as a whole. This includes updating back to an old
revision and recreating the files.

To implement this we only need the <hash> <local path> lines from the
.hgsubstate file along with one or more candidate URLs to clone from.
There is currently just one such URL, the one in the .hgsub file.

If we are just talking about a simple remapping because a repository has
moved, then my proposal seems sufficient. As for distributing the new
names for old URLs, what about if we read the .hgsub file from each head
similarly to how we read tags from all heads?

That would make it possible to override the URL used in an old revision
of a .hgsub file by remapping it in a new version.

I know there are performance issues whenever we want to "just" read data
From all heads. Perhaps it would therefore be better to store the
mapping as key-value pairs using my new favorite hammer: the pushkey
system. It seems appropriate to keep this as out-of-history metadata
since there should only be one global remapping per repository.

The mapping should still be augmented by whatever mapping the user
configures in his hgrc files.

-- 
Martin Geisler

Mercurial links: http://mercurial.ch/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20100717/2516c330/attachment.asc>


More information about the Mercurial mailing list