I’ve been using multiple version control systems for many years, and I’d like to make some observations.
> In the early 1980s, Tichy proposed the RCS (Revision Control System), which innovated with respect to SCCS by storing only the differences between the different versions of a file, as opposed to complete files. RCS is faster and uses less disk space than SCCS.
As I recall, SCCS also stores differences between files. One difference between SCCS and RCS is that SCCS stores the initial version of a file plus diffs for later versions, while RCS stores the latest version plus reverse diffs for older versions. Thus RCS is optimized for retrieving the latest version; in SCCS this would require retrieving the initial version and then applying an arbitrary number of patches.
> Lines are separated by a sequence of special characters that identify the beginning of a line.
The LF and CRLF sequences are end-of-line markers, not beginning-of-line markers. Typically every line has an end-of-line marker. Some systems tolerate a missing marker on the last line.
Your code sample starting with func difference has ” Tags often take the form of three numbers separated by dots: MAJOR.MINOR.PATCH (for example, 1.2.3).
Sure, but tags can be anything. The MAJOR.MINOR.PATCH format is just one convention for version numbers, and a tag can be used to mark a version that might not correspond to a release. Semantic Versioning is great, but it’s generally independent of the version control system.
First, with CVS we *first* got the notion of a collection of files as a single entity. With a simple “cvs diff” we could see *all* the changes across all the files in the repository. This was quite powerful compared to prior (like RCS), which only operated on one file at a time.
As an aside, CVS was backwards compatible with RCS. This meant I could point CVS at an existing collection of RCS files, and gain considerable function over folk just using RCS. (Also, I made some small contributions to CVS in the early 1990s.)
Second, I would suggest excising or reducing the bit about version numbers as tags. Like often true, the practice and conventions around version numbering is not inherent in source code version control.
You could write a distinct article about practices in version-numbering (particularly around product-versions), but do not be surprised if this generates more discussion than you might expect. At more than one job this topic ate weeks. :/
I saw a link to your article via Hacker news:
https://news.ycombinator.com/item?id=31113011
I’ve been using multiple version control systems for many years, and I’d like to make some observations.
> In the early 1980s, Tichy proposed the RCS (Revision Control System), which innovated with respect to SCCS by storing only the differences between the different versions of a file, as opposed to complete files. RCS is faster and uses less disk space than SCCS.
As I recall, SCCS also stores differences between files. One difference between SCCS and RCS is that SCCS stores the initial version of a file plus diffs for later versions, while RCS stores the latest version plus reverse diffs for older versions. Thus RCS is optimized for retrieving the latest version; in SCCS this would require retrieving the initial version and then applying an arbitrary number of patches.
> Lines are separated by a sequence of special characters that identify the beginning of a line.
The LF and CRLF sequences are end-of-line markers, not beginning-of-line markers. Typically every line has an end-of-line marker. Some systems tolerate a missing marker on the last line.
Your code sample starting with func difference has ” Tags often take the form of three numbers separated by dots: MAJOR.MINOR.PATCH (for example, 1.2.3).
Sure, but tags can be anything. The MAJOR.MINOR.PATCH format is just one convention for version numbers, and a tag can be used to mark a version that might not correspond to a release. Semantic Versioning is great, but it’s generally independent of the version control system.
Two comments (with sub-comments):
First, with CVS we *first* got the notion of a collection of files as a single entity. With a simple “cvs diff” we could see *all* the changes across all the files in the repository. This was quite powerful compared to prior (like RCS), which only operated on one file at a time.
As an aside, CVS was backwards compatible with RCS. This meant I could point CVS at an existing collection of RCS files, and gain considerable function over folk just using RCS. (Also, I made some small contributions to CVS in the early 1990s.)
Second, I would suggest excising or reducing the bit about version numbers as tags. Like often true, the practice and conventions around version numbering is not inherent in source code version control.
You could write a distinct article about practices in version-numbering (particularly around product-versions), but do not be surprised if this generates more discussion than you might expect. At more than one job this topic ate weeks. :/
Also, fearless refactoring is aided by version control. Version control even in individual work is an accelerator.
(This just popped up as new in my RSS feed…)