4 ms·

Speaking personally, definitely no. Even before I heard of git, I did not like SVN. In particular, it made an error I don't hear many other people mention where

by jerf 7y ago

Speaking personally, definitely no. Even before I heard of git, I did not like SVN. In particular, it made an error I don't hear many other people mention where directories were checked out to revisions, rather than entire repositories. Consequently it was very easy to accidentally update just a subset of your repository, and have your whole repository in a state that didn't exist in the version control system at all. There were several times there were builds that were completely unreproducible because it turned out that they were, technically, r83726, except this directory was r84713, but this other directory was r78372 except for a subdirectory that was r84299, etc. 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.

_ZeD_ 7y ago
>>> [SVN] made an error I don't hear many other people mention where directories were checked out to revisions, rather than entire repositories. that is a feature! You don't know how I miss that! (that, and the handling of blobs)
- shakna 7y ago
  Git still let's you check out particular directories at particular commits. It's just a specialised usecase rather than the default. git --work-tree=/path/to/outputdir checkout HEAD -- subdirname
- jerf 7y ago
  I would check, double-check, and triple check whatever use case you miss that for. It is a serious misfeature, and I find any workflow that critically depends on it to be very likely a process smell. Handling 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.
- dev_north_east 7y ago
  > that is a feature! You don't know how I miss that! Yep, handiest way to perform a first pass on narrowing down an introduced bug between a few commits.
  - jerf 7y ago
    Have you used "git bisect"?
bhaak 7y ago
None of the other big VCS had fatal flaws. If they had fatal flaws, they wouldn't have been used. 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.
- jerf 7y ago
  "None of the other big VCS had fatal flaws. If they had fatal flaws, they wouldn't have been used." 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.
  - bhaak 7y ago
    They still work. You can still develop with them. In that sense they aren't fatally flawed even today. 2018, 16% still used Subversion. https://insights.stackoverflow.com/survey/2018#development-practices 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.
    - jerf 7y ago
      You're really doubling down on applying deliberately hostile definitions to what I said, aren't you? I get to tell you what I meant. You don't get to pick the definitions I was using, especially after I told you you explicitly you picked the wrong one.
      - bhaak 7y ago
        You didn't really define what you meant with "fatal flaws". You just claimed that git didn't have them. 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/ https://xkcd.com/1597/ Using your tool wrong is not a fatal flaw of the tool.

by jerf 7y ago

_ZeD_ 7y ago

>>> [SVN] made an error I don't hear many other people mention where directories were checked out to revisions, rather than entire repositories. that is a feature! You don't know how I miss that! (that, and the handling of blobs)

shakna 7y ago
Git still let's you check out particular directories at particular commits. It's just a specialised usecase rather than the default. git --work-tree=/path/to/outputdir checkout HEAD -- subdirname
jerf 7y ago
I would check, double-check, and triple check whatever use case you miss that for. It is a serious misfeature, and I find any workflow that critically depends on it to be very likely a process smell. Handling 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.
dev_north_east 7y ago
> that is a feature! You don't know how I miss that! Yep, handiest way to perform a first pass on narrowing down an introduced bug between a few commits.
- jerf 7y ago
  Have you used "git bisect"?

bhaak 7y ago

None of the other big VCS had fatal flaws. If they had fatal flaws, they wouldn't have been used. 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.

jerf 7y ago
"None of the other big VCS had fatal flaws. If they had fatal flaws, they wouldn't have been used." 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.
- bhaak 7y ago
  They still work. You can still develop with them. In that sense they aren't fatally flawed even today. 2018, 16% still used Subversion. https://insights.stackoverflow.com/survey/2018#development-practices 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.
  - jerf 7y ago
    You're really doubling down on applying deliberately hostile definitions to what I said, aren't you? I get to tell you what I meant. You don't get to pick the definitions I was using, especially after I told you you explicitly you picked the wrong one.
    - bhaak 7y ago
      You didn't really define what you meant with "fatal flaws". You just claimed that git didn't have them. 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/ https://xkcd.com/1597/ Using your tool wrong is not a fatal flaw of the tool.