subrepo grand plan

Matt Mackall mpm at selenic.com
Fri Oct 14 12:04:33 CDT 2011


On Fri, 2011-10-14 at 11:48 +0000, David.Sedlock at lantiq.com wrote:
> Hi all,
> 
> I think it would greatly help the discussion and our team's planning
> for the future if the "grand plan" for subrepos (see
> http://markmail.org/message/k46azxwfwgmx572k) were explained in some
> detail, in particular, the guiding principles and the exact intended
> semantics of each of the commands (including rollback, egad!). What we
> have found in our internal discussions is that there is a lot of devil
> in the details (e.g. http://markmail.org/message/374pchj7wa5ajubf) and
> principles don't provide all the answers.
> 
> Now a few comments about the developments in the last 1-2 years and a request:
> 
> Matt stresses "transparency", which means that status doesn't report
> files that the other commands cannot operate on. Complete agreement.
> 
> But there is the obverse of this: other commands do not operate on
> files that status doesn't report. When we started with Mercurial,
> commit would commit files that status doesn't report as modified.

This is fair. The core principle at work here is that commit should
always commit a coherent snapshot of the whole project. We absolutely
cannot have a naked 'hg commit' commit everything but subrepos. But
indeed, people do have an expectation that if status reports nothing,
commit will not commit. I consider this to be a serious wart.

Patrick Mezard came up with a good compromise: abort if subrepos are
modified. This is great in that it doesn't break the coherency rule and
it keeps people from hurting themselves and is frankly how I should have
done it the first time around.

The only reason I haven't made this the default behavior is it breaks
backwards compatibility: people who actually want the convenience of
recursive commit will now have no way to do it. I might actually be
persuaded here but _no one's tried_. Instead people have tried to
convince me that commit recursion should be off by default entirely,
which is just obviously wrong and broken and not going to happen.

> Furthermore, unlike the commands that have the --subrepo option, which
> have recursive and non-recursive scope, commit has no non-recursive
> scope. Apparently an influential person noticed this and got a low
> level option added that provides a non-recursive scope for commit.

Anyone could have gotten that commit in. It was well-argued and
respected the expressed constraints. Though maybe that's what you meant
by 'influential'.

http://markmail.org/thread/7caj5epnr223kn3s

>  What we wanted Martin to do is simply extend the reach of this option
> and use it to finally get a predictable and consistent trio,
> commit/status/diff. 

And Martin's patch did not respect the expressed constraints. It
blatantly ignored them.

I said ages ago (and many times since) that I wouldn't take a patch that
changed the behavior of status with subrepos until add and friends
transparently handled its output. But for some reason I have yet to see
a patch that make 'hg add sub/foo' work.

$ hg st --subrepos
? sub/a
$ hg add sub/a  <- silently fails
$ hg st --subrepos
? sub/a
$ hg add sub/a --subrepos  <- misses the point
$ hg forget sub/a
not removing sub/a: file is already untracked
$ hg remove sub/a
not removing sub/a: file is already untracked
$ hg diff
$

> And it also would be great if a detailed grand plan were provided, so that we know we don't have to worry anymore!

The "grand plan" looks approximately like this:

make hg add accept explicit filenames in subrepos
make hg remove accept explicit filenames in subrepos
make hg forget accept explicit filenames in subrepos
turn on recursion in status BY DEFAULT
turn on recursion in diff BY DEFAULT
make hg add recurse subrepos BY DEFAULT
...
start deprecating all the useless subrepo switches

In other words, it should look this:

$ hg st
? sub/a
$ hg add sub/a
$ hg st
A sub/a
$ hg diff sub/a
diff -r 000000000000 sub/a
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/sub/a	Fri Oct 14 11:24:24 2011 -0500
@@ -0,0 +1,1 @@
+a
$ hg commit

See? It Just Works™, and with a minimum of new sharp edges introduced
between here and there. I don't understand why this is so hard and I
don't understand why we're even screwing around with short-term hacks
when this is so obviously where we want to end up.

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list