subrepo wish list

[Haszlakiewicz, Eric]

>-----Original Message-----
>From: mercurial-bounces at selenic.com
[mailto:mercurial-bounces at selenic.com]
>On Behalf Of Warren Postma
>
>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.

That seems to really conflict with the advice I've seen in other
messages about not being shy to create more repositories.  Whereas with
other revision control software I might have only one, I've tended to
end up with lots of repositories, and managing them all separately is a
bit of a pain.
What is the "doing it right" method for dealing with a project that has
multiple modules split into multiple repositories, but for which you
still want to be able to work with all the modules as a whole.  e.g. esp
when creating a release? 

>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.

CVS might have *started* with RCS "providing low level support", but
with current versions of CVS you're going to get into trouble if you try
to use rcs on its file directly, at least if you're not really careful.
There's a reason CVS was created: because those higher-level concepts
are much more useful to work with, and dealing with the lower level
operations is a pain.

> 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,

ugh, why do I need to use a gui?  I don't want to have to deal with a
gui, especially when trying to write instructions for the release team
to produce consistent builds.

> 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.

hah, well I, for one, think the repo-wide-commit behaviour is a bug.
Then again, I was (am) a subversion (and cvs) user for years. (as are
many people)

On the other hand, I think the idea that a commit (or any other command)
operates on everything within your current directory makes a lot of
sense.  Having an "hg commit" not commit files within repository that's
inside my current directory seems like it violates the principal of
least surprise, especially when I've explicitly set up that repository
as a subrepo.

eric