subrepo wish list

[Mina R Waheeb]

On Mon, Apr 19, 2010 at 1:15 PM, Warren Postma <warren.postma at gmail.com>wrote:

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

Same happened here for the entire company when we decide to use move from
centralized model


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

Well, if you mean the design/concept is not valid, I'll tell you that we
have tons of code managed by HG and linked together with subrepos. I agree
that its not mature yet like the rest of hg but all the core functionality
working and the rest will come just need sometime because with the large
scale of use its hard to take decision and abandon it late.


> 3.  confusion and frustration can result from poor features, and a product
> is better without a poor feature, than with it.
>

True, if it optional. What I'm saying that subrepo is requirement, We all
lived on forest extension for long time, large products and code base can't
live in one repo considering the use case is replacement of partial
checkout.


>
> 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*?
>
>
Another tool would give it more complexity in many ways (old scripts,
build/automation systems, extensions), backward compatibility is the most
lovely feature of HG and In the first place why we need another tool,
current internal implementation of hg subrepo load up and manipulate more
than hg instance AFAIK but what I'm sure of it MUST be transparent. The main
problem in subrepo that there is too may use cases and work flows, at least
the most common of em must be documented to prevent confusing the new users.

-- Mina R Waheeb



> Warren
>
>
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial/attachments/20100419/d6979490/attachment.htm>