subrepo wish list

[Warren Postma]

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.

 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.

 A perfect-storm user-story anti-pattern would be like this: User moves from
subversion to hg, user decides to immediately learn hg, subrepos, and mq on
day 1.  user gives up in disgust. user leaves.   I think that an hg design
tenet that most appeals to me, is "KISS".    complicated == fail.   simple =
understandable = success.   small repositories.  don't stick everything in
one repo.  don't build giant tangled piles of software at the hg layer.
 Build tools above the hg layer that use a first-word-on-the-command-line
that is not hg.  Remember cvs and rcs.   Remember the unix philosophy of
combining tools, rather than aggregating everything into one tool.

That's just my view.

Warren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial/attachments/20100415/a974ee40/attachment.htm>