CVS was awful, but it was so much better than RCS, which operated only on single files. There was a time in the late 90s when CVS + Bugzilla + Tinderbox was the state of the art of CI if your toolset was all open source. I used this combination at multiple workplaces 1998-2002. It worked and we shipped, but we didn't really understand how bad the tools were.<p>At Sun all stuff was in Teamware, except when it wasn't, because every group at Sun could do whatever they wanted to (we used SVN in the x86 ILOM team). Teamware was good but suffered by being a wrapper on top of SCCS.<p>SVN was a revelation after CVS. I resisted switching to git from SVN for a long time because the mental model for SVN is so much simpler: everything is in one central place, every change is marked with a monotonically increasing version number, remember a number and you can always reproduce the state of the project. Eventually I saw the huge benefit of the "git workflow" (local branches, pull requests) for collaboration. Branches in SVN are error prone and always risked painful conflict resolution, so we made them rarely.<p>Perforce, which is commercial, was like stepping into another dimension (you mean all this stuff just works? Out of the box?). There's another historical timeline where Perforce has an early open-source model (like Redhat) and is the dominant VCS.<p>I enjoyed that remembrance of 20 years working on free-software based projects, not a bad way to start Sunday. I hope it was worth your time!
This article makes in seem like ancient history, but there are still projects around that use CVS or very similar VCS like for example ClearCase. My software engineering career started after git got popular, but I had to work with ClearCase. I wouldn't wish it on anybody.<p>The inability to go back to old states of your project unless you happened to tag them makes finding the cause of bugs extremely hard. I don't know how it is in CVS, but in Clearcase you can tag only a subset of the files and what you check out from the server is determined by a complex configuration file ("the configuration specification"). This is an additional hurdle to reconstructing old states of your software because now you need to know the config-spec to do so. Even if you have the old config spec, it might contain fallback rules ("just take the latest version of the file") that effectively make it impossible to reproduce the old state. Unless you're extremely disciplined in your usage of the tool it's a real challenge to fix bugs for old releases. And don't get me started on trying to backport bugfixes into several old releases when branches are managed for each file separately.<p>This lack of a proper project wide history also makes it extremely challenging to migrate to a different tool without losing a lot of information.
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!<p>The way I see it the evolution of these version control systems was driven by the precipitously falling price of disk space.<p>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.<p>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.<p>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.<p>What's coming next?
I guess I’ve become an old greybeard while I wasn’t paying attention. When I started out in software development CVS, and later Subversion were the best we had.<p>The emergence of git and GitHub have transformed Open Source development, being able to just open a pull request or an issue and know you’ll get notified when things happen is great - I’ve submitted patches for many things which I just wouldn’t have bothered signing up to a mailing list to keep track of in the past.<p>Signed,
Github user 362 (from back before you could just sign up)
> When people talk about Git being a “distributed” system, this is primarily the difference they mean. In CVS, you can’t make commits locally. A commit is a submission of code to the central repository, so it’s not something you can do without a connection.<p>Not just commits - log, diff, status, almost everything I can remember needed to go off to the remote repository for information. Not only was this annoying when you didn't have connectivity, it was slow when you did.<p>I do occasionally miss the ability to version files individually though.
I wonder whether something like pijul (<a href="https://pijul.org" rel="nofollow">https://pijul.org</a>) might represent the next step forwards; I am no expert in these things but the patch based approach it takes sounds interesting and potentially very intuitive to work with. I might have to actually give it a go one of these days!
What would version control look like after Git ?<p>Git famously was not built for monorepo [1]<p>I would like to see sub-tree checkouts, sub-tree history, storing giant asset files in repo ( without the git-lfs hack ), more consistent commands, some sort of API where compilers and build systems can integrate into revision control etc<p>[1] <a href="https://www.youtube.com/watch?v=4XpnKHJAok8&feature=youtu.be&t=2595" rel="nofollow">https://www.youtube.com/watch?v=4XpnKHJAok8&feature=youtu.be...</a>
"Opening the Source Repository with Anonymous CVS."
Usenix 1999, by Charles D. Cranor (AT&T), Theo de Raadt (OpenBSD).<p><a href="https://www.openbsd.org/papers/anoncvs-paper.pdf" rel="nofollow">https://www.openbsd.org/papers/anoncvs-paper.pdf</a><p><a href="https://www.openbsd.org/papers/anoncvs-slides.ps" rel="nofollow">https://www.openbsd.org/papers/anoncvs-slides.ps</a><p>OpenBSDs involvement here is conveniently missing, arguably GitHub may not have ever existed.<p>Also of note, despite the paper being presented in 1999, AnonCVS was operating as early as 1995. Other projects were still putting tarballs on FTP, no read access to source history.
Others having mentioned the terror that was Clear Case, but I just want to highlight one of its bad features: everything was stored in a relational DB. And consistency was not guaranteed, so at one point all the code was corrupted. After recovery from the backup, it was retired with vengence, and everything went back to RCS and CVS.<p>When I wanted everyone to switch to Git or Mercurial (~2007) the main questions were about branch merges (MUCH easier in git than CVS) and the reliability of the version storage.<p>Many have now moved back to a centralised model of control (github), even if they have many partial copies. The incredibly RDBMS (non-git) method of managing the meta-data of github systems is very disappointing, but not surprising. If github is 4th gen, then I'm hoping for 5th gen, where all SE meta data is also available as a replicated database, which you can spin up with a local httpd.
My first professional coding job used SourceSafe which was lock-based so you couldn't even do concurrent versioning. Everyone had to take turns with the files.
I started my software engineer using CVS. I was using CVS as recently as 2014.<p>Why? Two reasons. I'd played with git but hadn't really understood the power of trivial branching (though I was one of those CVS power users who could branch, but tended to use my IDE to manage it). I remember thinking to myself, oh this is like CVS, because that is how I used it when I played with it.<p>The bigger reason is that I was managing a team of 2-4 developers that rarely worked on the same thing. We all worked in the same room. The codebase was relatively small (35k loc). I could see no good reason to make the change when CVS was "good enough". I was the same reason we used the same old crufty bug tracker--too many features to write to spend time upgrading infrastructure. Unless it was a 2x efficacy improvement; we did add automated testing and scripting around deploys because the benefits were obvious.<p>Now I love git and the power to branch and stage commits but I am still not sure it's needed for colocated teams of that size.
I didn't have much contact with CVS, but I used SVN quite a bit. Things I remember from these days:<p>* There was no separation between commit and push. How weird.<p>* "svn log" or "svn blame" would take ages, because it had to tal to the server.<p>* Well-run larger projects had branching guides, because the built-in commands didn't track enough meta data to do merges safely later on<p>* SVN made it trivial to checkout only a subdirectory of a bigger repository (which I still sometimes miss in git), so people often tracked different projects in separate directories of one repository.<p>The only thing I remember about CVS was that to clone something from CVS, you had to know some root directory (this presumably was the webroot), and sourceforge.net didn't show available webroots -- so there were tons of technically "open source" repositories that you still couldn't clone, because the webroot wasn't documented.
I enjoyed skipping the part of the article that explains how CVS worked, because I lived it. :)<p>CVS at the time felt like an amazing upgrade to RCS, just like Git feels like an amazing upgrade to CVS.<p>I wonder though, have we reached the end? If there anything beyond Git? When I used RCS, I would always lament "it would be nice if two of us could work on a file at the same time". When I was using CVS, I'd lament, "It would be nice if two of us could work on a group of files at the same time and merge our changes".<p>But using Git, my only lament is, "I wish this were easier for new developers" and "it would be great if there were a standard workflow". Problem one has been somewhat solved by GitHub/GitLab, and problem two has been solved by some pretty standard git-flow tools. Neither one really demands a new paradigm in VCS though.
I remember importing all our RCS files into our first CVS repository, around 1991. It was back when CVS was primarily used for maintenance of SunOS. As a result, this is the first commit in the repo I spend most of my time in:<p><pre><code> commit 0d92e7f51fa3e1dd3d2257e9900e7ea0b37d96de
Author: jkf <jkf>
Date: Mon Oct 21 07:53:43 1985 +0000
Initial revision
</code></pre>
RCS migrated to CVS which migrated to git.
RCS was okay if you were a sysadmin, terrible for everyone else. CVS was okay, but still limited. SVN was more advanced, but buggy as hell. Git is more advanced and less buggy, but over-complicated and unintuitive.<p>Git was actually started in order to complete core functionality and let someone else make the front-end for the VCS. But somewhere along the line people just decided they didn't need a user friendly frontend, and now the core is what people use every day. 13 years later and it's still difficult to use. Unless someone comes up with a really slick universal frontend for it, it's probably time for a new VCS.
A CVS lifesaver that you can put into your shell init file:<p><pre><code> export CVS_RSH=ssh
</code></pre>
This defaults to rsh and figuring out that I had to set it like this took me a shameful amount of time (mostly because it produces such and unhelpful error message). I literally couldn't pull the OpenBSD src tree for months...<p>I'm one of the few people who deliberately learned and used CVS (for a while) in recent times. I did not have any public repositories at the time and needed VCS for my configuration and some documents (Org mode mostly), and the model where I could have a central repository on a local directory which I could easily back up was compelling. Then I figured out a filesystem layout where I could back up all my work easily and this became useless, thus I switched to Mercurial. Nowadays I'm considering going just git, because it's what everybody uses, and Magit is a compelling piece of software.<p>I use RCS regularly along with Mercurial and Git nowadays. RCS is good for e.g. when I have a tree where most of the content is pdf files (papers), images, and other binary data that does not really need to be version controlled, together with an Org mode files for notes. I also have a pool of Elisp files which contain the personal bits of my Emacs configuration, and I use RCS on them because their histories are not related to one another. It's no good for projects anymore because it is essentialy a tool used when people used a single computer to develop software to which they connected w/ terminals, so they were all users of the same machine and the code was always in a determined location.<p>One thing people tend to confuse with CVS or SVN is that they think it's a client/server model whereas it's actually a repo/checkout model. The repo is central and can totally reside in a local tree, and checkins from different checkouts go directly to that repo. This is akin to sharing one .git tree between all your checkouts of a single repository.
> Did you passive-aggressively rewrite a coworker’s poorly implemented function out of cathartic necessity, never intending for him to know? Too bad, he now thinks you’re a dick.<p>When did it start to be like this? Making code better is a dick move now? Who rewrites stuff passive-aggressively? What does that even mean?
Nice article but the conclusion doesn't really follow from how the article is build up.<p>> It illustrates well why understanding the history of software development can be so beneficial—picking up and re-examining obsolete tools will teach you volumes about the why behind the tools we use today.<p>As the article re-examines this obsolete version management tool, it becomes clear it's pretty easy and straightforward and can do a lot of things that git can to a certain degree. On top of that it's dead-easy to setup and use, in fact, its simplicity might be an indication that's it's not all that obsolete and might be exactly the right fit for new small personal projects.
I see a couple of other references so I know I'm not unique, but my first experience of version control was SCCS on SCO Xenix. Then RCS, CVS, SVN and Git. I never used Perforce or ClearCase. Knew some folks who used PVCS and StarTeam and Visual SourceSafe.<p>I played with Bazaar, Monotone, Mercurial and Darcs but not enough to really appreciate them.<p>As an aside, I met Larry McVoy at a Linux convention in 1999 and heard him speak about BitKeeper. Those were interesting times.
My first job in the US ~2011 was in design team at monster.com.<p>One of the engineers had made a SVN repository for all our design specs and had cooked up a simple intranet page where the latest version of a design could always be shared by a permanent URL but also a history of all earlier versions.<p>That was my first experience with version control and I remember thinking it was magic. I never found out who made that, so if you’re reading thanks for going the extra mile :)
Though I had experience with cvs and subversion mostly through open source (mostly in sourceforge), I remember installing Trac around the time it first came out, and using that as equivalent to what would be done with GitHub today. Of course you had to have one install of it per project (or per 'organization', depending on your repository setup), and run it on a server somewhere.<p>Trac was great though, especially for the time: subversion server, source and changeset browser, tickets, wiki, roadmap. Aside from my own personal stuff, I switched several open source projects to it, and got a couple companies on to it. It quickly became to me an essential part of the dev stack, and was a great way to get the full dev stack* up and running relatively quickly.<p>* Other than continuous integration, but for me that came later. I worked on a lot of php stuff that could be deployed from source and never really saw the need then. Now I think it's essential and don't work without it.
> If cvs commit is what you were used to, then I’m sure staging and pushing changes would strike you as a pointless chore.<p>But using only `cvs commit` would be the equivalent of using a single script with git that adds every single thing in the relevant dirs and then blindly commits it.<p>In other words, the people coming from cvs and svn and complaining that git added a step for them were either doing an impeccable job of keeping their source dirs clean <i>at all times</i>, or they were implicitly admitting that they weren't keeping track of what they were adding to their own repos.<p>I would guess there are old projects that fit the latter description. But I know from experience there are old projects that clearly fit the latter.
This post does not do justice to just how awful CVS is.<p>OpenBSD still uses it, and it's the main reason I've only rarely contributed patches. CVS is just that crappy.<p>When I say it's awful I should admit that like FORTRAN it's not bad <i>for its time</i>. But 1986 was 32 years ago. It's not bad because it's old, but it's not 32 years of good either.<p>Commodore 64 was great for its time, but I'm not going to load my version control from a cassette player in 2018.
My professional career started in 2008, but I didn't personally use Git/Github until maybe 2010 or so, but it still took until 2015 for me to be able to use Git/Github at work!<p>Version control system timeline for me has been<p>IBM ClearCase -> CVS -> Perforce -> SVN -> Git<p>The non linear path is from switching jobs/working on legacy projects, but yeah.<p>Git has it's problems, especially on usability, but it's much better than all the others in that list!
While CVS may have originated with Grune, I think the CVS everybody is actually familiar with is the version Brian Berliner wrote and maintained for years.
My temporal progression went CVS -> SVN -> Mercurial -> Git.
Every one of those was a major upgrade in functionality except the last. I never fought against Mercurial, and I rarely needed to Google "how do you do X with Mercurial" because it was so intuitive. But I spend about 30 minutes a day fighting with or googling git. Git is a horrible mess, but I like everybody else am forced to use it.
> So I invite you to come along with me on an exciting journey and spend the next ten minutes of your life learning about a piece of software nobody has used in the last decade.<p>I know of companies who only very recently moved from CVS, and I'd bet there are many that still use it too..<p>Assertions like this are always dangerous, because inevitably, someone somewhere is still using that tech you think is long dead ;)
RCS was god. I loved RCS. Firstly, unlike SCCS it was head state so fast (SCCS recalced head from the history of change from base) Secondly, because it wasn't CVS all that branch and remote crappe was irrelevant.<p>I never learned CVS. My peers at work hate me because I think branches are something you prune off a rose bush in winter.<p>(I use git now)
This is a really interesting perspective for people who haven't grown up with Git. I'd not grokked a distinction between three generations of VCS before and it's strange to me to hear git's bad UI described as something other people think.
Used CVS with my team for years, say what you like, it was rock solid on branches.<p>I was appalled first time I had to pick apart a mess made by SVN on a branch.<p>I’ve made peace with git now, but struggled with the many different ways of getting things done in git.
CVS served its purpose <a href="https://en.wikipedia.org/wiki/Comparison_of_version_control_software" rel="nofollow">https://en.wikipedia.org/wiki/Comparison_of_version_control_...</a>
i work at a big bank that still uses CVS for most of their software. They use SVN for "modern" projects, and only recently started dabbling in git. The place is a tech museum.
YYMV. I once submitted a patch to OpenBSD without any prior knowledge of CVS and found it easier than my first contact with GitHub.<p>Pure git without GitHub may be a little easier than CVS.
> Do you enjoy spending 40 minutes repeatedly running git rebase -i until your local commit history flows like the derivation of a mathematical proof?<p>Hells no.
I think one has to work a little without a tool to truly understand why the tool has exists. Many new developers are forced to use git and they just don't understand why they have to go through this painful process.<p>I started without version control. I very quickly realised that it's very easy to break a project but forget how to undo your latest breaking changes. I discovered subversion and it was amazing. It was 2006 and I was the only person on my course to my knowledge who was using version control.<p>At around that time git came out and some people were trying it but many people said it was completely unnecessary for most projects. I then tried to use svn for a project with more than just myself as a developer and it was a disaster. We had giant commits once a day that cause conflicts every time. It was horrible. Git was truly amazing. I agree the cli isn't great (I use magit) but you have to have lived without it to understand why it's so important.
>Did you passive-aggressively rewrite a coworker’s poorly implemented function out of cathartic necessity, never intending for him to know? Too bad, he now thinks you’re a dick.<p>Woof, I bet this guy's fun to have at standup.