subrepo grand plan

Matt Mackall mpm at selenic.com
Tue Oct 18 11:57:30 CDT 2011


On Tue, 2011-10-18 at 10:15 +0000, David.Sedlock at lantiq.com wrote:
> Matt, many thanks for the clear reply. BTW, I believe in the
> "benevolent dictatorship". So let me test my understanding:
> 
> The principle is something like this: All commands that can reasonably
> be regarded as recursive will be recursive by default and there will
> be no way to defeat this.
> 
> Consequently, the low level option that provides a non-recursive scope
> for commit will be removed. ("We absolutely cannot have a naked 'hg
> commit' commit everything but subrepos.")

What option is that? What cannot happen is this:

 $ hg summary
 ...
 commit: 2 modified, 2 subrepos
 $ hg commit
 $ hg summary
 ...
 commit: 2 subrepos

..because now you've just accidentally committed a sin (pun intended):
your last commit breaks the build because it depends on uncommitted
changes in your subrepos.

It's critical to understand that Patrick's abort option prevents you
from sinning by accident:

 $ hg commit
 abort: uncommitted changes in subrepo foo

..which is what makes it an acceptable compromise.


> Right?
> 
> Now a few comments on details:
> 
> > make hg add recurse subrepos BY DEFAULT
> > ...
> > start deprecating all the useless subrepo switches
> 
> The "..." troubles me. I'll mention just a few commands: backout, branch, log, rollback, tag.

Well at the present rate, the '...' is years off, so we'll have plenty
of time to debate these issues.

> There are various ways of invoking commands where the recursive
> behavior has to be worked out in detail. A few examples: What does
> diff show when invoked with two revisions? Is the push --new-branch
> option passed to subrepos?
> 
> I would expect a plan to address these detailed issues and, if
> possible, get a reasonable consensus in the community.

Then you're going to be disappointed. I think anyone who can work out
all the details for how all commands should work A PRIORI is
significantly smarter than anyone I know. Waiting for that to happen
means it will never get done. Instead, we work incrementally and evolve
the project towards our goal, updating our goal as we get closer to it.
We know we're going to eventually need 'add' to work on files in
subrepos. So we do that. Etc.

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list