But disk was expensive, so you still didn't keep many versions of your code. SCCS solved that by keeping one complete version of your code, plus incremental updates. It also introduced version numbering, along with branching versions, so you could have version 1.1.1, and 1.2.5, etc. Because only incremental updates were saved, not much disk space was used; yet you could regenerate any back-version you wanted.
This system was cumbersome to use, and hardly anybody bothered with big, bushy, branching source trees.
Multiple access to the same source was implemented by allowing only one writeable version of a file to be checked out at a time. You would check out a file with a lock, edit it, and then check it back in. At that point, your teammate could check it out, edit it, and check it back in. If you wanted to check out a file that was already checked out by someone else, tough luck. You had to go find them and beat them up until they gave up the file.
In practice, you would wind up checking out a read-only copy of the code, make it writable (or take a writable copy), make your edits, and then merge them with a writable copy when you could get it.
RCS caused a number of conflicts in the workplace, and could have been responsible for originating the term "code ownership".
CVS accomplishes concurrent writable access by merging updates made by multiple parties and warning them when their updates conflict. You can incorporate your partner's changes into your working copy at any time, and you can commit your copy which means that your copy will be merged into your partner's, upon his/her request.
People working on the same source file will still have to resolve any conflicts detected by CVS. One wonders how this human interaction will be smoothed by fourth-generation version control systems.