The public MPS has no process for maintaining confidential extensions

[rptb1]

Ravenbrook supports the MPS commercially, including extending the MPS with confidential commercial code.

In the past we've used Perforce's Interfile Branching [citation needed] to maintain variant branches of the MPS for this purpose, and procedures based on Perforce. These will not function in Git, which has less sophisticated tools for branching and merging.

Ravenbrook needs to develop new process.

There's no reason we shouldn't share this process in the public MPS so that it can be adapted by anyone else who wants to do commercial support.

See also #76 #110

[rptb1]

Historical context: design.mps.config.req.prod is in the "retired requirements" section and says:

Allow product specific configurations of the MPS, so that we can build variants of the MPS for use in different products. This requirement has been retired on 2012-09-03 as part of work on the variety-reform branch. Client-specific customisation of the MPS will be handled in source control, while the MPS source remains generic, to reduce costs and increase reliability. See [RB_2012-09-13].

The branch index documents variety-reform as:

Reducing the number of varieties back to the original design of two (ish) with a hot variety that is fast with some checking and a cool variety that runs in reasonable time with plenty of checking.

My original analysis which led to the work is in [RB_2012-08-15], a key part of which is:

I'd like if possible to reduce the number of varieties to two: production/release and development/debugging. This is the model favoured by most modern IDEs as well, though they often support more than that. I think this would be best for MPS users.

Before this branch we had varieties to deal with:

• protecting trade secrets (obsolete since Ravenbrook acquired and open-sourced the MPS)
• continuing after an assertion (replaced by installable assertion handler in the plinth)
• switching on telemetry (replaced by making telemetry extremely cheap)
• collecting stats (not sure)

By discussing varieties here I am not implying that a build variety is the way to solve this issue.

But the statement "client-specific customisation of the MPS will be handled in source control" relied in Perforce inter-file branching and p4 integrate and Git just isn't as powerful.

[rptb1]

Git just isn't as powerful

To be clear, Git doesn't record enough information to implement something like p4 integrate. You can't build it on top of Git because Git doesn't record enough intentional information. There's no way to reconstruct lost intentions from the information in Git.