subrepo wish list

Michael Ekstrand michael at elehack.net
Thu Apr 15 13:54:28 CDT 2010


On 04/15/2010 09:43 AM, Warren Postma wrote:
> What do you think about the following "it's not HG's job" approach to
> subrepositories:
> 
> Subrepository extensions in hg are a bad idea. Nobody should stop
> anybody from doing whatever they want in an extension.  But subrepos are
> unmercurial, at least at first.
> 
> Put large caveats against using subrepo features right in the tutorials
> for hg.  If you think you need subrepos on your first day of using hg,
> you're doing it wrong.
> 
>  Encourage the idea that "No command line support for subrepository
> extensions whatsoever within hg" is an important way of separating hg's
> part in your workflow from other tools that operatate at a "meta-hg"
> level and provide higher level smoke-testing and continuous-integration
> workflows upon piles of repositories.   Remember RCS and CVS?  You have
> a tool (CVS) providing higher-level concepts and thus, higher level
> workflow support and another underneath it (RCS) providing low level
> support.

I think it is useful to be able to consider a repository reference (URL
+ changeset ID) as a member of a repository, which is exactly what
submodules do.  The primary use case I see for this is dependencies, and
this mechanism provides a clear way to say "this version of the code
works with this particular revision of the subproject/library".  While
it may be possible to implement that in an extension, it seems that
Mercurial would easily get confused if the base code does not have some
knowledge of them.  With the .hgsub implementation strategy, this isn't
too big a deal, though; I imagine it would be possible.

>  To me the "status" question is more of a "dashboard question".  I think
> a GUI  that has a LIST of my currently checked out mercurial repo
> locations, with the following table would be useful. I am thinking
> that this would be implemented as a set of additional hgtk style
> python+tk GUI stuff.    The main table for status would have these
> columns:  repo-path, repo-status-singleline, repo-description, etc.
>   
>  Your request for "always commit separately" rings very true to me, for
> me the reason is that repositories are too meaningful and atomic a thing
> to be combining them into any automatic hodgepodge of any sort. Thus I
> would prefer that the "hg" command line context remain forever only
> dedicated to single-repo operations.  hg commit means commit "THIS"
> repository, not this "hodgepodge" of whatever.    Thus subrepo
> extensions at the hg command line are confusing to me.
> If someone was perfectly happy with their pile-of-subrepos conceptually
> at the commit stage, who knows what fresh hell hg pull and push with
> subrepos could cause.
> 
>  I think visibility and clarity are key concerns for design of a source
> code control tool.  Visibility concerns should not ALL be addressed at
> the command line.  I think a clear division of "hg command line" deals
> with "this one repository where I am working" is a very good thing.
>  Some people are confused about "hg commit" doing a repo wide commit,
> even if you are in a subdir of your repo.  Imagine what fun that is,
> when you combine that with subrepos.

Yes, I agree that 'commit' should be 'commit this repo', with the
extension that 'a mercurial repository checked out at changeset X in
directory Y' being an entity of the current repository.

As I see it, automatically committing the subrepository is equivalent to
Mercurial discovering an Emacs lock file and telling Emacs to save the
edited file as a part of the commit.  Not exactly the behavior I'm
looking for.  Now, if it would tell me "Hey, you've got some Emacs lock
files here. Do you really want to commit?", that could be useful, and
would be the equivalent of the warn-and-force behavior I am proposing.

But I do think that some handling of subrepositories is appropriate for
mercurial.  That handling should just follow the Principle of Least
Surprise/Least Potential Damage.

- Michael



More information about the Mercurial mailing list