subrepo wish list

[Steve Borho]

On Thu, Apr 15, 2010 at 9:43 AM, Warren Postma <warren.postma at gmail.com> 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.
>  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.

I really like this 'dasherboard' idea.  It could support folder/repo
drop and allow the user to set the description (web.description).

>  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


--
Steve Borho