luckydude mentioned real per-file history for example¹, and that pushed me to remember per-file comments as the thing I'd want back.
Perhaps someone is listening.
The 4th paragraph from the end of section II talks about optional deltas. It's like ifdefs in a version control system: many version can be checkout with or without some of the deltas. While not part of many version control systems, it's an interesting idea explored in Andreas Zeller's Feature Logic PhD work 20 years later [1].
[1 - currently, SSL cert expired this morning; notified] https://www.st.cs.uni-saarland.de/publications/files/zeller-...
It strikes me that I treat the result of git-rerere as a ridiculously weak version of this. I'll occasionally carry an unwanted integration branch simply to handle changes that could be managed correctly if there was a better way to express relationships in my tools. Having the functionality baked in to the graph with the associated strictness, and available across clone boundaries would be great.
¹ https://www.cs.tufts.edu/~nr/cs257/archive/david-roundy/Theo...
I'm the main author of Pijul, and rerere has been my main argument in every discussion about Pijul to explain how everybody is trying to simulate commutation instead of really achieving it.
This is the first time I hear it from somebody else. THANKS!
Also, Darcs' theory doesn't really work around conflicts. Also, until recently, applying a patch in Darcs could take a time exponential in the size of history. It seems to be quadratic in the last few versions (Pijul is in log of the size of history).
It definitely appears to be a natural extension of the channels feature, but it isn't clear to me that you can express the actual relationship Zeller describes.
To me, SCCS is both a marvel and a disappointment. A marvel because its graph and weave were so far ahead of its time. A disappointment is because for the most part, time didn't build on the innovations, with TeamWare and BitKeeper among the exceptions.
Take the graph: storing history not just as a version graph, but also as a collection of deltas. The 3rd paragraph from end of section II:
"The second kind of special delta is one which, when applied, explicitly forces others deltas to be applied or not, by either including or excluding them. A list of deltas to be included or excluded is specified when such a delta is created. The exclusion facility is most often used simply to correct mistakes. For example if, after delta 3.14 is added, it is found to be undesirable, the programmer might add delta 3.15 which excludes it. If the module is accessed at level 3.14, delta 3.14 itself would be applied. If the module is accessed at a level 3.15, though, delta 3.14 would not be applied. From the viewpoint of control, this form of error correction is safer than allowing the programmer to actually delete a delta, since no potentially necessary information is lost."
Such advanced thinking from 1975! As for the for the brilliance of the weave, ... [1 - adding to mmastrac's reference of J. Schilling's wonderful SCCS pages]
[1]. http://sccs.sourceforge.net/sccs_invention.html