subrepo grand plan
Eric ROSHAN EISNER
eric.d.eisner at gmail.com
Wed Oct 19 17:24:31 CDT 2011
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:
> > 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...
More information about the Mercurial-devel