subrepositories and server-side operations.
In the wake of the fix for #310 (closed), I've realized that things good go bad in the presence of subrepositories with server-side operations that perform commits (file update, MR merge with explicit commit…)
Problem 1: each operation will reclone all submodules
First, updating to a given revision, the first thing that mergeability checks or actual merges do, will clone all the subrepos, which is potentially very long, and prone to fail. With the current way we perform all such operations (make a share at the starting revision), that really means to clone afresh.
On a project such as NMSDK, something so innocuous as adding a README would clone more that 30 repositories, so we might want to avoid that quite soon. It would be rather easy for the heptapod
extension to skip the update of subrepositories but…
Problem 2: Server-side operations are dangerous
For example, if a subrepository clone is missing from the working directory, any commit will set its entry in .hgsubstate
to the null revision.
So, if Heptapod stops cloning the subrepos for its server-side operations, or even is made more tolerant to cloning errors, adding a README through the Web UI could could corrupt subrepository revisions, perhaps in an impredictable manner, and, worse, publish it.
Problem 3: Conversion to Git
Our display of files in the Web UI still depends on some Git conversions, but hg-git
tries and converts the .hgsubstate
and .hgsub
files into the Git corresponding concepts, so these files won't be visible in the UI.
Short term actions
At some point, we will specify what Heptapod should do with subrepositories, but it will take some time to define a fully consistent behaviour. In the very short term (Heptapod 0.14.0 on 2020-06-29), here's what I could do:
- completely forbid any server-side commit if there is a subrepository configuration. It's a low-cost safety measure, and I already have a precommit hook ready to do that.
- if time permits, have all mergeability checks (except for fast-forward) directly fail if there are subrepositories.
- gain if time permits, have all other server-side operations refuse to perform if there are subrepositories.
In actions 2. and 3, it should be possible to provide a nicer user feedback than the strong error of 2, but I'm not sure if it's possible to do something really nice in time for 0.14.0.