I'm not disagreeing, though. I think you're right (for the "foreseeable future"). CVS, SVN, etc., really became serious obstacles once you moved to larger projects and more distributed teams etc. Hell, they caused problems even with small colocated teams.
I think it's clear that git (and its forerunners, esp. "BitKeeper") meets a solid "good enough" standard. Potential competitors from that era, including, in particular, "Mercurial", largely fall into categories of "trade-offs".
But, I am, personally, very happy to see the work that's been done with "Pijul", including completing a "theory of merging".
I don't think Pijul has much of a chance in even 10+ years of replacing git (and "GitHub", part of the success story of git). But, I do think it'll see some use, become a solid foundation for some projects, and, there's a reasonable chance it will influence or become the foundation of some "next git" and/or future versions of git.
With the caveat, of course, that forecasting anything on those kinds of timeframes is even more of a fools errand now than it was even ~15+ years ago (about when git was first developed).
Which "trade-offs" are you referring to?
Mercurial was, and still is, a solid DVCS. It's not often used today because it lost the popularity contest, due to several reasons[0], but technically it's as good as Git, and functionally it's even better. It has a much saner and friendlier UI, which is the main complaint about Git.
Mercurial, Darcs and Fossil are also interesting, and in some ways better than Git, but Git won because it had the persona of Linus behind it, one of the most popular and influential OSS projects using it as proving ground, and a successful and user friendly commercial service built directly around it, that included it even in its name. All of this was enough for Git to gain traction and pull ahead of other DVCSs, even though in the early days Mercurial and Bitbucket were also solid and popular choices.
I used and preferred Mercurial for a long time, but ultimately Git was more prevalent, and it felt like swimming against the current. I feel like that also happened with Docker (Swarm) and Kubernetes, where k8s is now the de facto container orchestration standard, much to my own chagrin.
I entirely disagree. Git was not an okayish solution to a problem that previously didn't have any okayish solutions. Git was trying to solve a new problem, and, as it turns out, it's a problem that a majority of git users don't have, and don't intend to have in the future.
I use SVN to this day, because I seriously believe that it's a better solution to the centralized version control problem than GIT. After SVN, centralized version control was basically a solved problem (or, at least, we had an okayish solution), so the next generation of tools (GIT, BZR, HG, FOSSIL) tried to solve a different problem, namely distributed version control.
But they made a complete mess of it (at least git did, I don't know the other distributed ones particularly well). A majority of git projects use centralized workflow and are subsetting the use of git features to only the ones that straightforwardly correspond to things that svn can do as well, and can do more easily. And the cost was a much more complex/convoluted mental model that a majority of git users don't truly understand in full detail, which gets them in trouble if edge cases turn up. Hence this joke [1]. With things like [2], you're basically seeing git becoming a parody on itself.
In SVN, any subdirectory of any repo looks pretty much exactly as if it was the root of its own repo.
Given that basic idea, you can accomplish things like branches, tags, links, and sparse checkouts through operations on directories, so there's no need for any special treatment of these concepts in the software (or your brain).
If your main branch is `myproject/trunk`, and you want to make a tag, just `svn cp myproject/trunk myproject/tags/v0_1`, done. If you never touch the copy, the tag will always keep "pointing" to what it is you want it to point to.
Want to start a feature branch? Just `svn cp myproject/trunk myproject/branches/my_feature`. Then check out that subdirectory and apply commits there instead of to `trunk`. When you're done, `svn merge myproject/branches/my_feature myproject/trunk`, done.
Want a special subdirectory `theirproject` that exists under `myproject` and points to a particular commit of `theirproject`? Assuming both are in the same repo just `svn cp theirproject/trunk myproject/trunk/theirproject`, done. Want to move the pointer to the latest version of `theirproject`? Just `svn merge theirproject/trunk myproject/trunk/theirproject`, done.
You can check out the directory tree at the point where you're actually working on it, and not have to consume bandwith to transfer the rest of the repo, not even when you check it out for the first time. This is super-useful for when repos get too large for their own good, or you want to do a monorepo covering many different projects. In GIT, trying to do "sparse checkouts" to accomplish this has driven me crazy on numerous occasions, in SVN it's totally natural.
An SVN monorepo thus allows one to make project structures a lot more fluent, adapting layouts as projects evolve. Permissioning is done at directory-level too. You can easily work out (and adapt, as needs change) your project layouts to fit your permissioning needs, or apply fine-grained (sub-repo-level) permissioning that respects your project layouts. Permissions aren't a big deal in open source projects, but they sure are when managing proprietary code.
I could go on, but the above is just an attempt to jot down some specifics that quickly come to mind.