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