subrepo grand plan

[Eric ROSHAN EISNER]

On Wed, Oct 19, 2011 at 14:59, Patrick Mézard <pmezard at gmail.com> wrote:

> Le 19/10/11 22:21, Matt Mackall a écrit :
> > On Wed, 2011-10-19 at 21:09 +0200, Martin Geisler wrote:
> >> Matt Mackall <mpm at selenic.com> writes:
> >>
> >>> On Wed, 2011-10-19 at 09:42 +0000, David.Sedlock at lantiq.com wrote:
> >>>
> >>>> commitsubrepos.
> >>>>
> >>>> This is the option we wanted Martin to use so we could get consistent
> >>>> behavior of commit/status/diff.
> >>>>
> >>>> The existence of this option cannot be consistent with your statement
> >>>> "We absolutely cannot have a naked 'hg commit' commit everything but
> >>>> subrepos."
> >>>
> >>> You haven't been listening carefully enough. There are THREE choices:
> >>>
> >>> 1) the current default behavior
> >>>    'a naked commit ... recurses'
> >>> 2) Patrick's commitsubrepos=False behavior
> >>>    'a naked commit ... aborts if subrepos are modified'
> >>> 3) the thing that everyone asks for (commit only the main repo)
> >>>    'a naked commit ... commits everything but subrepos'
> >>
> >> I just realized that there might have been some confusion here!
> >>
> >> The option I proposed is like *option 2*, not option 3. In other words,
> >> it does not allow you to commit the main repo alone. The recursesubrepos
> >> does two things:
> >>
> >> 1) it sets  commitsubrepos = recursesubrepos for commit
> >> 2) it sets opts['subrepos'] = recursesubrepos for status and diff
> >>
> >> That's all -- the goal is to let the user set recursesubrepos=False and
> >> get consistency between the commands as in this table:
> >>
> >>   If ui.recursesubrepos is set to a boolean B, then we have:
> >>
> >>             | recurses   | recurses
> >>             | by default | with --subrepos
> >>     --------+------------+----------------
> >>     commit: | B          | True
> >>     status: | B          | True
> >>     diff:   | B          | True
> >>
> >> The --subrepos flag is new for commit, it lets the user override the
> >> recursesubrepos option on the command line when needed.
> >>
> >> 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.
> >
> > 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.
> >
> > 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).
>
> Another point for (b) is that by minimizing interactions with subrepos,
> like not diffing subrepos by default, commands remain fast. Even with 2 or 3
> subrepos, I am afraid things could get slower if you have to run one svn
> diff command per subrepo everytime you run hg diff, especially on Windows. I
> still have a hack to make hgsubversion svnsubrepo use svn bindings if
> available for status/_wcrevs() calls, which helped with rebase IIRC.


Even with (b), committing a clean new revision of a subrepo is a change to
the repo contents that status/diff should (and currently do) reflect.
However, only under (b) could you optimize away actually running the diff if
the revision has not changed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20111019/46607364/attachment.html>