In the Unix arena, readily available tools of this kind are usually described as "source code control tools."
ATT's UNIX Source Code Control System. Most associated with System V UNIX systems, this package is available for most commercial "true Unix" systems, but not for the freely available ones as the code is encumbered by Unix source code licensing.
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.
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.
If this was useful, let others know by an Affero rating