But did you think that RCS, CVS, or SVN were also good enough? Or is this new?
That problem I saw even before I saw a replacement.
But once I saw git, having a full copy of the repo was pretty killer. It was also better at merging, partially for having the history local. In fact I recall some SVN people protesting at the time that merging wasn't so hard, but in a nutshell, they were just wrong. It was harder. Source control that can't merge fluidly is pretty limited from the get-go. There's literally entire dimensions of things we do with git that were so impractical with SVN that only the very largest projects could afford to do them, with the whole "workflow" question. Now you don't even hear about the difficulties of merging since all the open source SCMs copied each other and "good merging" is just table stakes now.
The problem is is that git doesn't really have fatal flaws, it has annoyances, and that's not the same thing. "The UI is difficult" is an annoyance for its target audience. Most every other criticism I've seen of it is an annoyance, not a fatal flaw. Fossil doesn't solve a problem I have with git. It has some neat ideas and arguably does solve some problems, but it doesn't solve the problems I have with git; you could lift Fossil's solutions to wiki and bugtracking and just put them in Git and I'd probably be happier with that than Fossil itself.
The problem isn't that Fossil is an SCM competing with git; the problem is that Fossil is a monolith competing with the rapidly-moving git ecosystem. The former is perhaps beatable, the latter is a juggernaut. All of Fossil's other features sitting in git is something that might get somewhere, but if the base source control isn't git-based, I can't sneak it into a work project to try it out. I've got a corporate mandate that all source belongs somewhere standard, and it's a perfectly sensible requirement for someone paying me to do a job.
that is a feature! You don't know how I miss that!
(that, and the handling of blobs)
git --work-tree=/path/to/outputdir checkout HEAD -- subdirnameHandling of blobs I can at least see preferring the differences, though git-lfs mostly acceptably shims that for me. The need to use git-lfs is definitely an annoyance, but it's another place where it's probably not a fatal flaw.
Or, to the extent that it arguably is, it would be when you're using git as something that it really, really isn't... it's a source code management tool. It's a good enough source code management tool that it's useful for many other things as well, like the way some people directly drive their personal websites with it. But it isn't a tool for managing lots of large files that can't be textually diffed, not a generic "content" management tool. I wouldn't expect git to necessarily store terabytes of video files, but then, it's not like Fossil is going to do that either from the sounds of it. git-lfs shims content blobs well enough to make it just an annoyance for source code management.
Yep, handiest way to perform a first pass on narrowing down an introduced bug between a few commits.
Fossil has bisecting with much the same CLI as Git, for what that's worth.
Sure, not being able to rename a file easily in CVS was quite an annoyance but nothing that made it completely useless.
There were always workarounds. But exactly those areas were workarounds or better tooling patches over stuff Git doesn't do are the areas that a possible successor will address.
That's just quibbling about definitions in fuzzy English. If you want to insist they weren't "fatally flawed" at the time, fine, but they certainly are relative to 2020 even by your definition.
2018, 16% still used Subversion. https://insights.stackoverflow.com/survey/2018#development-p...
But that's the hope, that we have something better by 2040, that makes today's Git look as outdated as CVS/Subversion looks to us now.
But if your Subversion example is one of those fatal flaws, then I just link to his example of Git usage that probably happens more often than we want to admit https://xkcd.com/1597/
Using your tool wrong is not a fatal flaw of the tool.
The other big thing was free cloud hosting for the repos.
Neither of these are unique to Git, obviously, or even introduced by it. It just happened to be the right combination of features and speed at the right time to become the winner of the popularity contest. Kinda like C.
And, just as C is still around, for all its numerous horrible quirks, Git will likely be around for a long time as well.
From what I saw, it was git vs hg - which had different philosophies. Hg gave you nice, polished workflow for supported tasks. Git gave you building parts that you can make your own system from. It turned out that enough programmers wanted to build from parts.
SVN required a centralized server and didn't even supported branching, so no.
One can argue about what a branch is, for sure. Subversion branches, Mercurial branches and Git branches all have very different implementations.
But the main workflow of creating a feature branch, developing a feature, then merging it back into the trunk/master, has, as far as I know, always been supported in Subversion.
SVN's official response to branching and tagging was to copy directories around in the repository. Arguably that means it does not support branching, at least according to the concept that has been in place for the last decade.
However, don't let that confuse you. The "svn copy" command creates a new place where you can do independent development, and where afterwards merging back can occur. So it's the same as a branch by that definition.
An "svn copy" is a lightweight copy, with a reference back to the place the copy was made from.
- "svn merge" does its merge by looking at what commits have been made at the original location (since the copy), and the commits to the copy.
- "git merge" does its merge by looking at what commits have been made on the original branch (since the new branch was created) and the commits on the new branch.
So "svn merge" and "git merge" act in the same manner. (Of course there are differences in the algorithm, but I wish to refute the point that Subversion "does not support branching [at all]".)
And if you never use "svn merge" or "git merge", then a branch is just a copy, in either system.
It was not a naming issue. It was a bona fide lack of support for a basic feature. The manual itself states quite clearly that in SVN land you create a branch by copying around the entire working directory within your repository. SVN's manual is quite clear on how SVN actually tracks the state of a file system, and not the state of a source code tree. By copying the working directory around the repository you're creating new revisions of your file system. That' it. Just because you can diff two directories it does not mean copying a directory around in a file system is a branch. And nor is it a tag.
It did have problems with occasional inexplicable tree conflicts, which I do not miss. But that's the same as the pain of trying to rebase in git when things have diverged and it just starts spewing repeated conflicts for each and every commit. In either case, the easiest thing to do is make a fresh branch, patch your changes over, and go from there vs. trying to reintegrate the broken branch.