From time to time, I do a 'pijul pull -a' into the pijul source tree, and I get a conflict (no local work on my part). Is there a way to do a tracking update pull? I didn't see one, so I toss the repo and reclone. What works for you in tracking what's going on there?
From time to time I get curious about Pijul, attempt to pull the Pijul repo from the nest, and encounter a no-workaround-possible bug in the network sync. I have never been able to do a fresh clone of Pijul.
It is very hard to take a project like this seriously.
May get complicated at the edges, as files move across boundaries. It's a hard problem. And for some subset of those problems, subtree does give a way to split and join.
Baumol’s Cost Disease or Baumol Effect [1]. Thanks for mentioning. I think it deserves more air time, especially looking at typical responses (raising price, reducing quality) and the consequences (raising prices raises expectations, triggering more investment causing prices to go up more). How to reduce consequences? Two models that seem to work are volunteer based organizations, such as AA[2] and education organizations coupled with technology, specifically AI, such as Khan Academy's Khanmigo[3]. What does this mean for universities? Lots of terrain to explore looking for sweet spots.
[1] There are the standard places to define like Wikipedia. The link I offer here is an A16Z podcast with Marc Andreesen and Vijay Pande where Marc gives an overview about 3 minutes in.
> The data received was SCCS, which was an understood format with existing tools.
You'd be surprised. SCCS is not broadly understood. And BK is not exactly SCCS.
I read the SourcePuller code when it was published (sp-01). It's pretty easy reading. I give Tridge credit for that. I wrote a little test, got it to checkout the wrong data with no errors reported. Issue was still there in sp-02 .
Rick saying "I worked on BK" is the understatement of the century. He showed up and looked at my code, I had done things in a way that you could have walked the weave and extract any number of versions at the same time. He was really impressed with that. I split apart stuff that Rick had not seen before.
Then he proceeded to fix my code over and over again. I had a basic understanding of SCCS but Rick understood the details.
Rick knows more about SCM than any guy I know.
And he is right, SCCS is not well understood and BK even less so.
I had him as a teacher for my 2nd CS class in 1976, I think it was data structures using Pascal. I don't think I had another class which we laughed so much. Enough learning and fun that I considered switching my major from EE. And then he left to be part of the project that became Ada. It was still a good class, but it became a normal class. I stayed with EE. Thank you, Prof. Wulf, for that glimpse of something bigger. It stayed with me.
The blc.S didn’t build for me using `-oformat:binary` . Changing to `--oformat=binary` it compiled, but then get core dumps. Running Linux x86_64 up to date Ubuntu 20.04.4 .
for cc in cc gcc clang
do echo "## $cc"
$cc -no-pie -static -nostdlib -o blc -Wl,--oformat=binary blc.S || exit 1
{ printf 0010; printf 0101; } | ./blc; echo
done
This amazing paper holds a special place in my heart: my marked up 1992 copy serving me well when working as a graph and weave engineer on BitKeeper.
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]
After seeing luckydude answer questions on the little thread the other evening, I'm wondering what other things the SCCS/BK folk think we should be doing better. What have we forgotten?
luckydude mentioned real per-file history for example¹, and that pushed me to remember per-file comments as the thing I'd want back.
Branch operations should be first-class transactions in a revision control system. In Git, if you rename branch "foo" to "bar" there's even less record-keeping in place than changes to files. Instead, there should be a first class transaction in the repo history that represents this change.
A reasonable direction to go, and I'll give sort of a non-response. For me, it's to take some time to absorb and celebrate this paper. If I go too quickly to doing better, I tend to miss the amazing. It also makes it easier for me to talk about other's contributions (like luckydude's many) to the state of the art, as then get into what could be better.
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].
Zeller's design seems to be addressed at least in part by darcs/pijul using the methods described in David Roundy's Theory of Patches¹. A virtual filesystem seems like an especially nice way to solve the interface issues that would arise too.
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.
> It strikes me that I treat the result of git-rerere as a ridiculously weak version of this
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).
If you're familiar with the Zeller paper... Was I right in believing that the approach you're using in pijul allows the use of optional deltas as Zeller's paper describes? I was planning on digging around a little more next weekend, but if you happen to know.
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.
I'm not familiar with that thesis. Pijul uses deltas everywhere (but a special form of deltas, storing more information than the output of `diff`), plus tricks to make that fast.
From time to time, I do a 'pijul pull -a' into the pijul source tree, and I get a conflict (no local work on my part). Is there a way to do a tracking update pull? I didn't see one, so I toss the repo and reclone. What works for you in tracking what's going on there?