On subrepo support in hg-1.3

[Matt Mackall]

On Tue, 2009-07-14 at 10:37 +0200, Martin Vejnár wrote:
> Hi,
> 
> I've recently noticed that a subrepo support has been added as an 
> experimental feature to Mercurial 1.3. I'm glad that it has finally 
> found its way to the core distribution.
> 
> For the record, I'm one of the authors of the hgdeps extension 
> <http://mercurial.selenic.com/wiki/DepsExtension>, which basically does 
> the same thing as subrepo. There is however one major design difference, 
> which is what I'd like to ask about.
> 
> subrepo stores the revision-subreposet mapping by storing the 
> appropriate subreposet in .hgsubstate file for the given revision. On 
> the other hand, hgdeps stores the entire mapping explicitly in .hgdeps 
> file. Only the newest version of the file is used when the mapping needs 
> to be consulted. This approach is very similar to how tags are handled 
> (the entire revision-tag mapping is stored in .hgtags file, only the 
> newest file is used).
> 
> While the former approach may seem cleaner and more elegant, I believe 
> it suffers from two major drawbacks.
> 
> 1. It won't be possible to update the mapping if the remote changesets 
> get renumbered. As we've all witnessed many times, repositories tend to 
> get converted from one versioning system to another (the svn->hg 
> conversion seems to be popular these days). It would be frustrating to 
> have subrepos stop working on older revisions, just because someone 
> finally decided to move to Mercurial.

Well conversion won't affect us yet as we currently only have support
for hg subrepos. But yes, if you rely on an external and the external
goes away (by being renumbered, converted, moved, or the like), then
you've got a problem. Having a way to say 'revision A of B is now X of
Y' years after the fact would be interesting. Vaguely related to the
problem of email addresses in the changelog becoming invalid - we could
use a way to remap those as well.

But in general, it's probably best if projects make their 'externals' a
little less external if they depend on being able to reconstruct all of
history.

> 2. An existing project will not be able to set up subrepos 
> retroactively. This also means that projects that use one of many 
> existing dependency-handling extensions won't be able to easily covert 
> to subrepo.

Yes, I haven't given a lot of thought to that.

> Has the .hgdeps/.hgtags-like approach been considered? If it was, what 
> are the reasons it was rejected?

No, I hadn't really considered that approach. Generally Mercurial makes
it a rule to have history be backward-facing only. Things in the past
are generally not affected by things that happen in the future. Tags are
about the only exception to this: you can decide to change a tag in the
future and affect a build in the past. If you move 1.0, you won't be
able to build the old 1.0 any more.

-- 
http://selenic.com : development and support for Mercurial and Linux