subrepo wish list

Chad Dombrova chadrik at gmail.com
Mon Apr 19 01:00:19 CDT 2010


i'm having trouble reconciling these ideas:

>  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

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

> You have a tool (CVS) providing higher-level concepts and thus, higher level workflow support and another underneath it (RCS) providing low level support.

with this:

> small repositories.  don't stick everything in one repo.  

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

i agree that a proper mercurial workflow involves the use of lots of small repos, but how can we have this without being able to track the relationships and dependencies between these repos?  this seems like a pretty fundamental ability that should not be passed off to a higher level tool. if i am instead forced to rely on some higher level tool to accomplish this, then someone else who clone's my repo will also need this tool just to get my dependencies.  that seems pretty ridiculous to me, unless maybe i'm misunderstanding your intent.

i think that subrepos need improvement (you still can't clone a shared repo with subrepos!), but despite its failings this is still a native feature that is sorely needed.  is this really something we want every high level tool to solve in their own way?  

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


if a user of any software gets frustrated trying to learn the most advanced features of that software on the first day, then the fault really lies with that user and not the software.  mercurial has a nice easy learning curve, and that is a testament to its solid design, but yes, it does also have advanced features that take time to learn.  so are you suggesting that these advanced features should be nixed for fear of alienating some small population of users with poor learning skills?

-chad




More information about the Mercurial mailing list