subrepo wish list

Warren Postma warren.postma at gmail.com
Mon Apr 19 08:15:06 CDT 2010


>
>
> so, your idea is lots of repositories with no native way to track their
> relationship?
>

No way native to hg itself means two things:

1.  Users develop the concept that hg operations are "repositorial".
2.  Another tool that is called something else (mhg for "meta-hg") handles
"meta-repositorial" operations.

I have seen the following frequently on this list:

1.  refugees from CVS and SVN have an inaccurate mental model of hg
operations due to prior experience with CVS and SVN which have different
designs.  I got trapped here myself. Initial results with subrepos were so
unsatisfactory for me that I considered dropping hg entirely and going to
something else.
2.  the sub-repo model can be used as a crutch to continue mentally reliance
on the CVS and SVN mental models.    Or an excuse to abandon hg entirely,
because face it, the subrepo model is half-baked.
3.  confusion and frustration can result from poor features, and a product
is better without a poor feature, than with it.

I think that by having an "affordance" (in user-interface design
terminology) creates an expectation of functionality that I think was never
fully designed into the model created by the original designer of HG.  It is
like saying that I have designed a car, and this car is very similar to a
schoolbus, it only needs a trailer behind it with seats added.    I would
argue that hg makes a very good handler for a single hg repo, when an hg
repo is correctly understood. Bolting on the meta-repository level, I think
that it weakens the overall model.

I guess I'm saying: Are we not capable of typing "mhg"  (meta-hg) and having
a separate tool here?  Is it not the work of five minutes to make this a
separate tool (written in python of course) that can load up and manipulate
hg, or even merely interact with hg via its official public command-line,
and would that not be *better*?

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


More information about the Mercurial mailing list