4 ms·

SVN seemed irreplaceable not so long ago and CVS before that and RCS before that... When someone comes up with something demonstrably better and gets the right

SVN seemed irreplaceable not so long ago and CVS before that and RCS before that... When someone comes up with something demonstrably better and gets the right people to start using it, people will switch over.

rhabarba 7y ago
Note how POSIX still has SCCS as the default VCS (and it is still fine for single file commits)...
colechristensen 7y ago
SVN also had serious difficulties and performance limitations which git does not. Git is somewhat confusing to use, but not enough so that anyone really cares all that much (besides a few people who really care) and that is not a recipe for easy replacement. There were/are slightly less confusing version control systems (mercurial) but they didn't catch on for whatever reason.
- emodendroket 7y ago
  I mean so is Unix and it's still around all these years. Heck there's nothing especially obvious about a for loop, yet every language has them. Once everyone's accustomed to the weird interface they are just going to demand everything else have the same weird interface they're used to. This is one of the lamentations of the Unix Hater's Handbook.
  - wwright 7y ago
    If you’re talking about a “for (initialize; condition; step) { body }” for loop, most newer languages don’t have them AFAICT. I would say the other kind of for loop, a “for x in y { body }” loop, is very intuitive and obvious to most English speakers. We use idioms like “for each A, do B” all the time.
    - emodendroket 7y ago
      I meant the C-style one and they do appear in most commonly-used languages, though I guess most commonly-used languages are not all that new.
  - teleforce 7y ago
    Git is probably destined to be Unix for our generation that was born after Unics/Unix invention. It is not a coincident that the designer/programmer of the most popular Unix version/clone of our generation is the same guy who designed and programmed Git.
- vmchale 7y ago
  > There were/are slightly less confusing version control systems (mercurial) but they didn't catch on for whatever reason. Also (sorta) darcs, and hopefully pijul. I sincerely hope some patch-based version control can catch on.
  - rhabarba 7y ago
    I would love to see a merger of Pijul and Darcs again. Having two diverging patch-based approaches (one declining, one not lifting off) is not a good thing.
    - vmchale 7y ago
      I think darcs has an algorithm which is not really suited for large repositories with many users contributing. pijul regrettably seems to be broken most of the time, but I don't think it's irredeemable.
- foota 7y ago
  Doesn't git fall apart for long wide checkouts and large files?
  - colechristensen 7y ago
    Git doesn't work very well when trying to version control things which aren't text and are large binary files. There's an acceptable workaround which is only a little awkward with git-lfs. The general consensus is that putting big files in git means you're doing something wrong and the problem is with your environment not git. (or there are special-purpose tools for your kind of workflow which handle the specifics of your use case, like CAD/CAM/etc.) Workflows like that generally don't fit into nice little boxes anyway the way source code management does.
    - braindeath 7y ago
      > The general consensus is that putting big files in git means you're doing something wrong and the problem is with your environment not git. This is not a “general” consensus. It’s a consensus among hardcore proponents of git. I love git, it has made my life better. I still think it’s large file support story is shitty/suboptimal, and there are valid use cases where a general purpose VCS is used to track large binary assets along code and git would do well to be a general purpose VCS. It’s a limitation of git. It’s not a fatal limitation, and git still has enough benefits (which include availability and mindshare), but it is still an unfortunate limitation and somewhat ironic for a tool born in a world where everything is just a “sequence of bytes”.

rhabarba 7y ago

Note how POSIX still has SCCS as the default VCS (and it is still fine for single file commits)...

colechristensen 7y ago

SVN also had serious difficulties and performance limitations which git does not. Git is somewhat confusing to use, but not enough so that anyone really cares all that much (besides a few people who really care) and that is not a recipe for easy replacement. There were/are slightly less confusing version control systems (mercurial) but they didn't catch on for whatever reason.

emodendroket 7y ago
I mean so is Unix and it's still around all these years. Heck there's nothing especially obvious about a for loop, yet every language has them. Once everyone's accustomed to the weird interface they are just going to demand everything else have the same weird interface they're used to. This is one of the lamentations of the Unix Hater's Handbook.
- wwright 7y ago
  If you’re talking about a “for (initialize; condition; step) { body }” for loop, most newer languages don’t have them AFAICT. I would say the other kind of for loop, a “for x in y { body }” loop, is very intuitive and obvious to most English speakers. We use idioms like “for each A, do B” all the time.
  - emodendroket 7y ago
    I meant the C-style one and they do appear in most commonly-used languages, though I guess most commonly-used languages are not all that new.
- teleforce 7y ago
  Git is probably destined to be Unix for our generation that was born after Unics/Unix invention. It is not a coincident that the designer/programmer of the most popular Unix version/clone of our generation is the same guy who designed and programmed Git.
vmchale 7y ago
> There were/are slightly less confusing version control systems (mercurial) but they didn't catch on for whatever reason. Also (sorta) darcs, and hopefully pijul. I sincerely hope some patch-based version control can catch on.
- rhabarba 7y ago
  I would love to see a merger of Pijul and Darcs again. Having two diverging patch-based approaches (one declining, one not lifting off) is not a good thing.
  - vmchale 7y ago
    I think darcs has an algorithm which is not really suited for large repositories with many users contributing. pijul regrettably seems to be broken most of the time, but I don't think it's irredeemable.
foota 7y ago
Doesn't git fall apart for long wide checkouts and large files?
- colechristensen 7y ago
  Git doesn't work very well when trying to version control things which aren't text and are large binary files. There's an acceptable workaround which is only a little awkward with git-lfs. The general consensus is that putting big files in git means you're doing something wrong and the problem is with your environment not git. (or there are special-purpose tools for your kind of workflow which handle the specifics of your use case, like CAD/CAM/etc.) Workflows like that generally don't fit into nice little boxes anyway the way source code management does.
  - braindeath 7y ago
    > The general consensus is that putting big files in git means you're doing something wrong and the problem is with your environment not git. This is not a “general” consensus. It’s a consensus among hardcore proponents of git. I love git, it has made my life better. I still think it’s large file support story is shitty/suboptimal, and there are valid use cases where a general purpose VCS is used to track large binary assets along code and git would do well to be a general purpose VCS. It’s a limitation of git. It’s not a fatal limitation, and git still has enough benefits (which include availability and mindshare), but it is still an unfortunate limitation and somewhat ironic for a tool born in a world where everything is just a “sequence of bytes”.