Subrepository remapping plan

Martin Geisler mg at aragost.com
Fri Jul 23 08:44:35 CDT 2010


Dirkjan Ochtman <dirkjan at ochtman.nl> writes:

> On Fri, Jul 23, 2010 at 13:38, Martin Geisler <mg at aragost.com> wrote:
>> I've made a wiki page that describes what I'm planning on implementing
>> for remapping URLs in the .hgsub file:
>>
>>  http://mercurial.selenic.com/wiki/SubrepoRemappingPlan
>>
>> Please take a look and tell me if you think this will solve your
>> problems. The plan comes from the company that has hired me to implement
>> this, and we believe it will solve their problems.
>
> Nice, that provides a good overview.
>
> I'm missing two things from this page:
>
> - Why do we need the separate subpaths file? If that's because we
> don't consider hgrcs writable and we want pushkey-based distribution,
> that's fine, but it would be nice to have stated explicitly

Good point! The reasoning is that we don't want to mess with peoples
config files as you say, but also that we need a place to store the
"factory default" settings. The idea is that the .hg/subpaths file is
refreshed automatically on every pull. If you add an override to
.hg/hgrc, then that override should survive the next pull.

I may not get around to updating the wiki tonight -- others are welcome
to jump in. In any case, I'll get back to it after my vacation.

> (it could also help to reorder so that the existence of the subpaths
> file is more clearly related to the distribution section).

Okay, makes sense.

> - Why do we need the intermediate key "libfoo"? It seems like we could
> just use the in-repo path to the subrepo to key off of (i.e. the
> subpaths file or hgrc would have lib/foo =
> http://hg.company.com/libraries/libfoo). It might change location in
> the repo, but it wouldn't be hard to add an extra mapping entry (the
> libfoo is also prone to being renamed at some point).

Ah, that idea is new. The original idea was to solve the problem of
outdated URLs, and this is why I propose we remap URLs (= right-hand
sides in the .hgsub file).

If we base the remapping on the left-hand sides instead, then we base it
on something which can already change today, but something which causes
no problems when it change. The problem is changing right-hand sides.

If the "libfoo" key is renamed, then one would keep remappings in place
for "libfoo" and begin working with a, say, "libfoo2" key.

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://aragost.com/mercurial/


More information about the Mercurial-devel mailing list