On subrepo support in hg-1.3

[Martin Vejnár]

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.

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.

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

Best regards,
-- 
Martin Vejnár