subrepo grand plan

[Martin Geisler]

Matt Mackall <mpm at selenic.com> writes:

> On Wed, 2011-10-19 at 21:09 +0200, Martin Geisler wrote:
>
>> I'm sorry if my explanation was confusing in the original patch:
>>
>>   http://selenic.com/pipermail/mercurial-devel/2011-September/034354.html
>
> Ok, you're right. I managed to misread both your description AND your
> code the last time around. Thanks for having patience with me.

No problem -- it seems I cannot remember and you cannot read :-)

> But I'm still not super-excited about this. Let me lay out some
> related options for comparison:
>
> a) Work towards having commit/status/diff consistent AND recursive by
> default
> b) Make commitsubrepos False by default
> c) Add your recursesubrepos option, None by default
>
> My favorite is (a) because all work here is forward progress towards
> having subrepos more uniformly integrated. This will make subrepos
> better for everyone with no config settings needed. I think the big
> hurdle here (getting these three commands consistent +
> add/forget/remove) is really not that hard given the existing
> groundwork you've set in.

Yeah, I hope so.

> I ought to have done (b) to start with or very early on, but the
> option never occurred to me. Now I frankly think it's half a step
> backwards. It'll solve a big issue for new users (great), but may
> upset some existing users (which usually trumps). Given that we've got
> four months until the next release this could possibly be in, I'd
> rather see us hurry up and do (a).
>
> And (c) I think is not especially better than the status quo. New
> users will still have to find it to get the consistent experience, and
> then when we finally do (a), they'll have to go back and turn it off.
> Then there's collateral maintenance issues, tool awareness and so on.
> Given that it's purely a stop-gap measure, it's a half-step backwards
> plus a log to trip over when we start going forward again.

It's definitely a stop-gap solution and not very discoverable for new
users. Maybe we can keep it in the back of our heads for when we get
near 2.1 and then put it in if we're still not done with (a) then?

> I'd really rather get to the point where this whole issue is in the
> rear-view mirror.

Yeah, me too :-)

> Here's my subrepo Top 5 wishlist:
>
> 1) nested repo paths on hosting services

That would be a good step forward.

> 2) make 'hg add/forget/remove sub/foo' work so that we can make
> status/diff recursive

I'm actually surprised that 'hg add -S' doesn't work... I'll have to
test this more.

> 3) make subrepos track what they last pulled so we don't waste time
> trying to push clean / read-only repos
> 4) more parity between hg and git/svn subrepo support
> 5) better docs / use cases on the wiki

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://mercurial.aragost.com/kick-start/