rbsmith

If you don't know otherwise, then no. Version control has always been a small market, and with Git, it's harder, because that sweet spot has been removed.

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.

This is more a response to many of the comments here than to the article, offering a perspective of what value they might bring.

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 half of my life in that world, I get it: secret sauce. I don’t expect much to be said for a while.

Do you use Pijul?

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 no way to separate it

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.

I worked on bk

> 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 .

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.

Yes! Thank you. On to exploring!

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

Any suggestions?

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.