subrepo grand plan
laurens.nospam at grauw.nl
Thu Oct 20 09:59:32 CDT 2011
Op 20-10-11 14:09, Jason Harris schreef:
> On Oct 20, 2011, at 6:43 AM, Dirkjan Ochtman wrote:
>> On Wed, Oct 19, 2011 at 22:21, Matt Mackall<mpm at selenic.com> wrote:
>>> a) Work towards having commit/status/diff consistent AND recursive by
>>> 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.
>>> 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.
>> I'm with Patrick in that I prefer (b) even now. I find his argument
>> about predictability and scalability of performance compelling, but
>> mostly I find recursive commit (by default) plain scary.
>> It's way too easy to inadvertently commit in the child repo (and only
>> notice on push), and I thoroughly dislike the fact the subrepo gets
>> the commit message from the parent repo by default, which often
>> doesn't describe the changes in the subrepo very well. Also, after
>> you've inadvertently committed a subrepo and you want to roll that
>> back, you have to do an incredibly awkward dance where you rollback
>> the subrepo, commit again something more appropriate (e.g. better
>> commit message or only parts of the changes), then you have to fix up
>> the parent repo which is a pain because the recorded revision for the
>> subrepo no longer exists, etc...
> I also think the default should be (b)
Me too, for what it’s worth.
(b) seems perfectly fine behaviour, some arguments:
* No additional tool support is needed because I can just open the
subrepo in another TortoiseHg window (I did this with git and it works
* You won’t have to deal with automagic behaviour that passes through
some options to subrepos and some not.
* You won’t have to deal with trying to map Mercurial commands and all
its option to Git and SVN. I think this will never really work well and
have a ton of caveats, plus it will make it significantly harder to add
commands and options to Mercurial.
* Mercurial commands will stay fast. In an SVN project with 6 subrepos
here, ‘svn status’ is annoyingly slow while in 99% of the cases I am not
interested in the changes in the subrepos at all.
The only real downside is that hg status will show .hgsubstate as
modified instead of indicating the subrepository paths, but I can live
with that if that is what is required by existing tools.
More information about the Mercurial-devel