3 ms·

The point was that these were either dismissed or weren't considered by Kay when describing breakthroughs in computer programming. They aren't breakthroughs in

The point was that these were either dismissed or weren't considered by Kay when describing breakthroughs in computer programming. They aren't breakthroughs in computer programming languages, but IMO are breakthroughs in computer programming. > RCS - 1982 CVS - 1990 I don't accept CVS as a breakthrough in the same way as git has been. Back in 2000 - 10 years after CVS - using source control wasn't a given. We had articles like "The Joel Test"[1] encouraging teams to use source control. CVS was a pain to set up and limited once you did. Thanks to git (and DVCS in general) using source control is the default for 1 person throwaway projects up to projects with thousands of contributors and million lines of code. [1]: https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/ https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...

setpatchaddress 5y ago
SVN fixed a lot of the issues with CVS, FWIW; setup, maintenance, robustness were much improved. But, yes, git was a major breakthrough. Even if you ignore the advantages of a DVCS and git's raw speed, git provides the ability to branch freely, with reasonable confidence that you can merge without spending days reconstructing your divergent source ("merge hell").
citrin_ru 5y ago
> We had articles like "The Joel Test"[1] encouraging teams to use source control. IMHO source control used more widely nowadays not thanks to git per se, but thanks to availability of free VCS hosting platforms like github.com Subversion IMHO is more beginner friendly than git, but we AFAIR didn't have good subversion platforms (with cheap of free private repos). Sourceforge added SVN in 2006 (which is late), but sourceforge GUI is an abomination and there are reasons not to trust it: https://en.wikipedia.org/wiki/SourceForge#Controversies https://en.wikipedia.org/wiki/SourceForge#Controversies
- hnfong 5y ago
  I suspect this has a lot to do with the architecture of git allowing relatively "dumb" servers. To run a git server, you only need the capacity to receive, serve and compare git hashes and blobs. For SVN at least (last I used it), the server is expected to perform all sorts of potentially expensive operations (esp. for large repos): diffs, merges, branches, etc. since the client does not have the full repo/history. Given at the time computing power was less cheap, it would mean that hosting SVN services incurred a non-trivial cost. (And IIRC CVS was so bad that I don't think anyone in their right mind should actually try to host a free/cheap service around it.) Also, initial versions of SVN was released around 2004, while git 1.0 was technically in 2005. It took a while for people to get used to git, but given its technical superiority (and its momentum given Linus' approval) and being less demanding on the server side to host, hosting for git was a correct decision to make anyways.

setpatchaddress 5y ago

SVN fixed a lot of the issues with CVS, FWIW; setup, maintenance, robustness were much improved. But, yes, git was a major breakthrough. Even if you ignore the advantages of a DVCS and git's raw speed, git provides the ability to branch freely, with reasonable confidence that you can merge without spending days reconstructing your divergent source ("merge hell").

citrin_ru 5y ago

> We had articles like "The Joel Test"[1] encouraging teams to use source control. IMHO source control used more widely nowadays not thanks to git per se, but thanks to availability of free VCS hosting platforms like github.com Subversion IMHO is more beginner friendly than git, but we AFAIR didn't have good subversion platforms (with cheap of free private repos). Sourceforge added SVN in 2006 (which is late), but sourceforge GUI is an abomination and there are reasons not to trust it: https://en.wikipedia.org/wiki/SourceForge#Controversies https://en.wikipedia.org/wiki/SourceForge#Controversies

hnfong 5y ago
I suspect this has a lot to do with the architecture of git allowing relatively "dumb" servers. To run a git server, you only need the capacity to receive, serve and compare git hashes and blobs. For SVN at least (last I used it), the server is expected to perform all sorts of potentially expensive operations (esp. for large repos): diffs, merges, branches, etc. since the client does not have the full repo/history. Given at the time computing power was less cheap, it would mean that hosting SVN services incurred a non-trivial cost. (And IIRC CVS was so bad that I don't think anyone in their right mind should actually try to host a free/cheap service around it.) Also, initial versions of SVN was released around 2004, while git 1.0 was technically in 2005. It took a while for people to get used to git, but given its technical superiority (and its momentum given Linus' approval) and being less demanding on the server side to host, hosting for git was a correct decision to make anyways.