ATT's UNIX Source Code Control System. Most associated with System V UNIX systems, this package was long available only for commercial "true Unix" systems, but not for the freely available ones as the code has been encumbered by Unix source code licensing.
More recently, it was released by Sun as part of OpenSolaris, and code is available at SCCS @ berlios.de .
Less-encumbered clones have, on occasion, been released. MySC, an SCCS-compatible version control system, was written in C++ by Ross Ridge, whom I knew well in my days in Waterloo. It has recently been revived as CSSC.
Overview and comparison with RCS. Note that the current maintainer recommends that people not use CSSC outside of the circumstances that they:
Cannot use RCS as a substitute,
Cannot use CVS and RCS as a substitute,
Really need SCCS, but cannot use it due to it being unavailable.
Walter Tichy's Revision Control System has become extremely popular on many platforms (including MS-DOS), particularly as decent freely available source code is available. It was developed subsequently to SCCS, and provides some improvements out of lessons learned in the design of SCCS.
Unlike SCCS, which stores the original version along with patches that transform the file into the current version, RCS takes the opposite approach of storing the current version along with patches to move back to older versions. This is usually faster, as people usually are most interested in the most recent version. It is rare for the original version to be of much importance 25 patches down the road.
The Concurrent Version System provides more sophistication than RCS; it builds a versioning system to manage groups of files on top of RCS. RCS manages single files at a time; CVS uses the RCS toolset to manage all of the source code for a project. All of the BSD operating system projects ( NetBSD , FreeBSD, OpenBSD ) use CVS to manage the "core" set of software in one manner or another.
Some of the BSD OSes use more extensively the client/server nature of CVS, and do public administration (with differing degrees of "publicness"); they provide access to source code trees where multiple developers can simultaneously check in code.
The former approach is preferable early in the development cycle, when new versions involve large changes in design, and "multiple cooks" spell chaos. Once the overall design is relatively stable, the latter approach becomes practical.
The Cathedral and the Bazaar describes the "Linux Method" of managing software projects; tools like CVS can be very useful for doing this.
Linux uses essentially GIT to manage release of new versions; updates to the central source tree are managed by a "benevolent despot" (Linus Torvalds and some "trusted lieutenants").
CurVeS - Screen-oriented UI for CVS.
Distributed Concurrent Versions System (DCVS)
DCVS extends the well-known version control system CVS and the file distribution and synchronization program CVSup with functionality to distribute CVS repositories with local lines of development and handle synchronization of the distributed repositories automatically in the background.
Aegis is a project change superviser somewhat similar to CVS.
CryptoGnome is an attempt to reinvent the wheel without reinventing the wheel. In other words, it appears to me that the combination of elements in rfc1945 (HTTP) and rfc1521 (MIME) can be very simply extended to provide the foundation of a network-oriented version control system. Security comes relatively cheaply from the use of https and the http native authentication framework.
The goal of the Subversion project is to build a version control system that is a compelling replacement for CVS in the open source community.
svk is a decentralized version control system written in Perl . It uses the subversion filesystem but provides some other powerful features, such as distributed branches, lightweight checkouts, advanced merge features, and more...
This system creates a virtual file system containing file versions; it uses an RDBMS such as PostgreSQL as a data repository. It apparently has similar performance to CVS when one uses a lightweight RDBMS, but is slower when using a "full-featured" relational database.
Created for the EROS project, this is intended as a better alternative to CVS.
arch is a distributed version management system. Distinctives include:
Implemented originally as a set of shell scripts, targeted at high portability;
Uses FTP as its main distribution mechanism;
Quite fancy schemes for revision merges ;
Unlike CVS, it copes accurately with renaming of files, directories, and handling of symbolic links;
Several versions have emerged from the efforts, including:
It combines version management functionality (think of RCS as perhaps the simplest example of a system to manage that), source code control (ala RCS, SCCS, CVS), configuration management (which more or less corresponds to the rules of a Makefile ), and building (corresponding to the recipes of a Makefile).
Unfortunately, while it is theoretically portable, bootstrapping it to new systems is nontrivial, as it expects to use itself to build itself. And its use involves a methodology that is on the one hand quite different from that of other tools, as well as being fairly complex to learn.
The Emacs text editors offer integration with many of the preceding version control systems so that you may edit code using Emacs, and control check-ins without needing to leave the text editor.
There are also a number of IDE (Integrated Development Environment) tools which commonly include support for version control software.
etckeeper is a tool for tracking configuration in /etc in an SCM repository such as Git, Mercurial, Darcs, Bazaar. It includes hooks to allow package managers such as Debian apt to automatically commit changes made during package upgrades.
It doesn't automatically make things "backgradable", but adding automatic tracking of when configuration changes is a most awesome thing.
What I am still trying to figure out is whether or not there is a good way of collecting etckeeper configuration from a number of hosts into a single Git repository. That would enable doing decentralized backups of one's system configuration, which seems like a mighty useful idea.
Mighty useful material... This indicates how to set up a git repository in one spot on your favorite host, and use it to manage web pages (and such) in another spot. That way the .git directory isn't part of the published material.
A good book on Git which I appreciate having in both "dead tree" and electronic form.
This article presents the use of Git with a bias to those that are accustomed to the use of centralized SCM systems (like Subversion).
Arguments in favour of preferring Git over other SCMs.
This is a "visual cheatsheet" that categorizes the kinds of actions doable in Git based on interactions with different parts (stash, workspace, index, local repo, remote repo).
People are frequently using Git to do more or less novel things:
git-annex allows managing files with git, without checking the file contents into git. This is useful for collections of music, videos, or documents, where it is not important to capture versions, but where you'd like to be able to migrate documents around, make sure there are multiple copies, and such like.
DVCS-Autosync - A personal Dropbox replacement based on Git
Dropbox has grown quite popular, as a widely-accessible service where you can "drop" your files. (There are getting to be integration tools for mobile platforms such as Section 1, for which this particular system is sadly not a replacement...)
But it's not obvious that the operators of Dropbox are infinitely trustworthy in all ways. One might wish to run one's own file distribution service, and here is a nice example of such.
A backup system with a number of interesting qualities:
Breaks large files into chunks, detecting (much as with rsync) that repeated mostly-the-same copies of files are mostly-identical and so do not need to be repetitively copied
Uses the Git packfile format for storage, so you can access data using Git methods
Writes packfiles directly, so it's faster than Git
Shares data automagically between backups.
The really cool part is that this means that files that are identical are stored once, not multiple times, even though the source systems are unaware of each other. Thus, data in /usr/lib and /usr/share will tend to be "less redundant than expected", and the more sources you back up into one bup repository, the more redundancies, and hence, savings, you may expect to find.
There is a problem with this - you can't trivially purge old data.
Something called "par2 redundancy" allows recovery from corruptions
If this was useful, let others know by an Affero rating