An important part of being (or becoming) a professional programmer is learning to use version control. We therefore recommend that everyone experiment with version control even when it doesn't matter - when the projects you deal with are relatively small - so that you have less to learn later when it really matters.
Here in DoC, several version control systems are setup, mainly on Linux it has to be said, but some are accessible even from Windows and across the network. Here's a quick list of the most obvious ones:
Git
Git is the revision control tool used by a great many open-source projects, and by CSG internally. It's use is required for some courses in the first- and second-years, and is becoming the tool that we recommend people learn to use by default for new projects, particularly group projects.
See also our notes on using Git in DoC.
GitLab
GitLab is a GitHub-like flexible GIT-based collaboration tool for projects with arbitrary members. All members of DoC can use GitLab, create projects, add other DoC members to their project (with particular levels of privilege) etc. Find gitlab documentation at:
SVN: Subversion
SVN is a much better replacement for CVS; when the project started, it set itself as the goal, "CVS done right". General documentation may be found at http://svnbook.red-bean.com/ and man svn.
However, to get you started, we have two guides of detailed instructions to create your own SVN repository and add projects to it, one for your personal use, the other for group project repositories.
Historic Version Control systems you might meet
While noone should probably create a new project using one of these systems, you might also work on projects already maintained under one of them, so this information is included largely for historical interest:
RCS: The Revision Control System
On Linux systems here in DoC, the simplest single-user version control system is called RCS. Dating back to the 1980s, it picks a small and simple part of the "project management" space, and implements it very simply and robustly.
The basic idea of RCS is that, in each directory where you store files of importance - source code, documentation and other textual files - you create an RCS directory (mkdir RCS) and then tell RCS to version control each important file via the command:
ci -u FILENAME1 FILENAME2 ....
At this point, those filenames are "checked in" (ci) to the version control system, their initial contents are stored in the RCS directory as version 1.1, and a readonly ("unlocked") copy of the file appears in place of the original.
To edit a file, first "lock it":
co -l FILENAME
this modifies the RCS directory to create version 1.2 of the file, and makes the copy of the file in the current directory writable. Now you can edit it with your favourite editor:
pico FILENAME
Having made your changes, quit the editor updating the file. Recompile your program, test it, when you're happy that you've made a sensible set of changes to one (or more) files, review your changes with:
rcsdiff FILENAME1 FILENAME2...
Now, commit your changes as version 1.2 by:
ci -u FILENAME1 FILENAME2...
The checkin command will ask for a short summary of the changes you've made. type a line of text, then "." on the next line to finish the input. If you're checking several files in, you'll be asked whether to apply the same message to each subsequent file. Just press RETURN if so..
For more details, see
man rcsintro
CVS: The Concurrent Version System
RCS is very simple but doesn't handle the case where multiple developers want to cooperate on a project, and work independently (making changes to separate copies) before checking their changes back into the master copy. Those developers might be accessing the version repository across the network too!
To be honest, having to separately manage RCS files in multiple directories is a bit of a problem for single-user large projects!
CVS was the first widespread attempt to tackle this larger problem. It has now been superceded by Subversion and more modern distributed version-control tools, like git. We strongly discourage its use for projects new and old, and recommend that you import any existing repository into a more modern system.
If you must use CVS, look at the following for more details:
man cvs
SCCS: The Source Code Control System
Ok, this is too old-school even for us. Seriously, SCCS was replaced by RCS in the 1980s, for goodness' sake! SCCS had a major design flaw: it stored the full text of the original version and then stored a forward patch for each later revision. This meant that typical operations (such as "give me the latest version of file X") slowed down badly over time. A fix was added to store the full text of each major version (i.e. 2.0, 3.0 etc). RCS was designed to store the full text of the latest version and back patches for each earlier version. Don't use SCCS. Ever. Really!
