This is a really fun article. I started with CVS, graduated to Subversion, and now to Git. It makes me really curious what the next paradigm shift will be!
The way I see it the evolution of these version control systems was driven by the precipitously falling price of disk space.
CVS only stored a tiny bit of metadata locally so almost every operation required contacting the server. That made using CVS very slow and branching expensive.
Subversion stored a whole separate copy of every file locally. This made the critical "show me just my local changes" operation an order of magnitude faster and made branching cheap, at the expense of doubling the disk usage.
Git stores the entire history of everything locally (compressed). This makes most operations an order of magnitude faster still, so much faster that some things that were completely impractical with the earlier systems is now routine, and branches are free.
It's possible to check out partially without hacking, so should be in a better place than git in that respect. Other than that I'm not sure if there is any support (similar to LFS). It's also very much in its infancy so performance is likely not a primary focus.
> ... makes me really curious what the next paradigm shift will be
I know this is HN and we need to know 100 git commands. We should do interactive rebase, we should cherry picking changes, and all that jazz, but I really hope the next source control will be a whitelisted git commands subset. push, pull, commit, amend and rebase or something similar.
> I know this is HN and we need to know 100 git commands.
The ones that I normally use are fetch, merge, push, reset, rebase, clone, diff, status, branch, log and checkout. When I used svn, I had to use co, commit, add, delete, diff, status, log, copy, and update. Eleven versus nine commands, so the difference isn't really that much.
I followed pretty much the same path as you over the past 30+ years. I am curious at how easily you adapted from the centralised to distributed 'mental map'? I struggled with that a lot, especially with everyday things like 'checkout' and 'commit' doing subtly different things in SVN vs Git.
I actually started with CMVC, an IBM proprietary VCS which was horrible. CVS or pretty much anything was an improvement over that so I had no problem making that switch.
I was an early adopter and promoter of Subversion. I loved how much faster it was than CVS, although it took me a few years to fully understand some of the more complex things like the details of merge tracking.
I was very resistant to Git at first - I fundamentally just didn't get it. The whole concept of a distributed VCS seemed like anarchic nonsense. I basically had to be dragged there kicking and screaming, but of course now I'm very comfortable and would never go back to Subversion.
Everyone rightfully complains about Git being hard to use but it's totally worth it for the power. It seems unlikely to me that the next generation will be "works like Git but simpler to use". I think whatever comes after Git will have to be more significantly different than that.
The way I see it the evolution of these version control systems was driven by the precipitously falling price of disk space.
CVS only stored a tiny bit of metadata locally so almost every operation required contacting the server. That made using CVS very slow and branching expensive.
Subversion stored a whole separate copy of every file locally. This made the critical "show me just my local changes" operation an order of magnitude faster and made branching cheap, at the expense of doubling the disk usage.
Git stores the entire history of everything locally (compressed). This makes most operations an order of magnitude faster still, so much faster that some things that were completely impractical with the earlier systems is now routine, and branches are free.
What's coming next?