rbsmith
Long live CDC Update!
> who is intended to be TFA's audience
I got something from seeing that last diagram. True, I don't know what features that future work will bring, but see that what ever it is, they want to keep it mappable to Git. Staying mappable to Git is a tether that can limit or reward creativity.
You posted before Steve's response[0]. Does that help?
If you have some great reasons to say yes (Perforce, GitButler, ERSC) such as better technology targeting some industry, 2-way bridge to Git and connections in a market, then you wouldn't be listening to me.
If Git works well enough, great! If not, maybe a different system fits better[0].
I’ve spent about 35+ years in and around version control / SCM, with half of that being part of the BitKeeper team, where my job was to think about sets, graphs, and weaves in the context of a team making commercial customers’ lives better along with benefit to open source world.
If Git is good enough for you, know that it is not true for everybody. For some subset of that everybody, it’s worth paying to have that pain go away. And part of having that pain go away is being able to stay connected to all that is, to be enough of a superset of the current world, to not be better in an incompatible way. That’s what I see in the pictures Steve and team draw: world that interacts with Git in a way that is better for some willing to pay to have the pain go away.
I agree nothing much is being said about the Non-Git Storage Engine. As I’ve spent much of that 35+ years in that world, I get it: secret sauce. I don’t expect much to be said for a while.
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?
There is
git subtree --help
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.
[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.
https://a16z.com/podcast/baumols-cost-disease-in-healthcare-...
[2] https://aa.org
> 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 .
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
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-...
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]
About 10 years ago, I did a round trip a month, each under $300 and all flights non-stop. Then USAirways hub status left, and the pain set in.
Do you have references? I've heard of these but haven't come across details after much creative searching since they are common words.