subrepo grand plan

[David.Sedlock at lantiq.com]

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. If Matt's principle is called "transparency", we might call this "predictability".

So we asked Martin Geisler to add a --subrepo option to status. Now we could at least achieve predictability. Martin added the option to some other commands to keep them in line with status: if status reports modified files, diff should show what was modified. (This of course meant settling one of those devilish details: what diff should report in subrepos when it is invoked with two revisions in the parent repo.)

But then the next problem was what we might call "consistency". The partner of commit with no options is not status with no options but status with the --subrepo option. The poor luser now needs to remember that an unadorned status won't actually tell him what an unadorned commit will do.

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. 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. 

I really don't understand the opposition here (see http://markmail.org/message/k46azxwfwgmx572k). Right, the change does not make the commands transparent. But they are not transparent now - the change doesn't make it worse. We will be happy when the development community releases a Mercurial that is transparent, predictable and consistent with respect to subrepos. Meanwhile, we need some short to medium term solutions.

So it would be great if the opposition to Martin's small improvement were reviewed.

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

Regards,
David

Lantiq Configuration Management Solutions
http://wiki.lantiq.com/display/IT/Configuration+Management __________________________________
Lantiq Beteiligungs- GmbH & Co. KG
Registered Office: München, Commercial Register: Amtsgericht München, HRA 94167
Limited Partner (Kommanditist): Lantiq Intermediate Holdco S.à r.l
General Partner (Komplementär): Lantiq Beteiligungs Verwaltungs- GmbH
Registered Office: München, Commercial Register: Amtsgericht München HRB 180523
Managing Directors (Geschäftsführer): Christian Wolff (CEO), Dr. Klaus Gohlke (CFO)
___________________________________________
Important Note: This e-mail may contain trade secrets or privileged, undisclosed or otherwise confidential information. 
If you have received this e-mail in error, you are hereby notified that any review, copying or distribution of it is strictly prohibited.	
Please inform us immediately and destroy the original transmittal. Thank you for your cooperation.