CVS stands for "Concurrent Versioning System" and is a way for multiple programmers to work on the same source code at the same time without stepping on each other's feet. To use CVS you must first get a "checkout" - this is almost but not completely unlike checking a book out of a library. You don't have to return it, but you can if you make useful changes. It is usually just a fancy way to download the source code to your computer.
CVS may not be installed by default on your system. For debian-based systems, it can be installed by executing
sudo apt-get install cvs
For other systems, you can either search the net for a compatible package, or get the source and compile on your system. Source is available from the CVS project homepage at http://www.nongnu.org/cvs/.
For more information on how to use CVS, read the "CVS Book": http://cvsbook.red-bean.com/cvsbook.html
There are two ways to get a CVS checkout: anonymous or developer checkout. Unless you are a registered developer, you will be using an anonymous checkout.
To do an anonymous checkout, type the following at a shell prompt:
cvs -z5 -d:ext:firstname.lastname@example.org:/cvs co emc2
To do a developer checkout, substitute your cvs username for "anon" in the above command:
cvs -z5 -d:ext:<username>@cvs.linuxcnc.org:/cvs co emc2
If you are checking out a tag or a branch, specify it on the co commandline with "-rTAG_OR_BRANCH":
... co -rTESTING emc2
The "-d" argument specifies the directory that will be created for the CVS checkout.
To track new feature development, use no "-r" argument. This is called the "CVS TRUNK" (or sometimes, incorrectly, the "CVS HEAD"):
cvs -z5 -d:ext:email@example.com:/cvs co -demc2-trunk emc2
To track a particular branch, use "-rBRANCHNAME". For example, to get the latest bugfixes before the next release in the 2.2.x series,
cvs -z5 -d:ext:firstname.lastname@example.org:/cvs co -rv2_2_branch -demc2.2-branch emc2
To get a particular version of emc, use "-rRELEASE_X_Y_Z" (a "release tag") to get version x.y.z. For instance, to get released version 2.1.6, use
cvs -z5 -d:ext:email@example.com:/cvs co -rRELEASE_2_1_6 -demc2.1.6 emc2
Later, to incorporate any changes made to the emc2 source by other developers, run
cvs -z5 update -Pd
in the top emc2 directory.
To show changes you've made in your private copy of emc2, run
cvs -z5 diff -u
in the top emc2 directory. You can also redirect the output to a file (<html>cvs diff -u > ~/diffs.txt</html>), for instance to send to the developers' mailing list for discussion and possible inclusion in emc2.
Some old versions of CVS may require that you
before issuing cvs commands.
Note: Because of reliability problems with sourceforge, and
because we want some features not provided by sourceforge, we
have moved our CVS to a privately-hosted server and
maintain it ourselves. Developers need to submit their SSH public keys to Chris Radek, a process that is described in DeveloperAccess
If you don't want to remember all the options and switches by heart, you can put most of them in a textfile in your home directory and name it .cvsrc
Typically it would look something like this:
cvs -z5 -q
The first line will make cvs always run in quiet mode (-q), and use compression (-z5) which saves bandwidth.
The second line will make all update commands Prune empty directories (-P) and create missing directories (-d).
The third line will make diff use the unidiff format (-u).
After an initial checkout (see above), you can then do an update, diff or commit simply by
If you want the command to act on just one file you can do
cvs <command> filename
individual commands may also have a flag to select recursive or non-recursive behavior.
Developers can "commit" their changes to the tree, making them available to other users. When committing you should write a short message that describes the commit. By default cvs will open an editor for you to write the message, but if desired the commit message can be specified on the commandline:
cvs commit -m"this is a message"
You can only commit changes from a developer checkout, not an anonymous checkout.
If you wish to submit a patch, please observe the following guidelines:
* For new features and non-bugfix improvements, use the CVS TRUNK version as a basis (either the TRUNK or a the active vX_Y_branch are appropriate for bugfixes)
* Make an effort to follow the prevailing indentation style of surrounding code. In particular, changes to whitespace make it harder for other developers to track changes over time.
* Generate patches with "cvs diff -up" (or "cvs diff -u" if -p is not supported)
* When possible, make sure each patch addresses only one bugfix or improvement
To submit a patch, there are several different options:
* Submit it as an item on the sourceforge tracker: http://sourceforge.net/tracker/?group_id=6744 -- submit bugfixes in the "bugs" section. submit improvements in the "feature requests" section.
* Subscribe to the emc-developers mailing list, and send the patch to the list as an attachment. However, there is a 24kb limit on messages to this mailing list.
* On the #emc-devel IRC channel, post a link to your patch (on a site like http://pastebin.ca or on a private server) and ask if a developer will look at it. When using a 'pastebin'-type service, choose the option that retains the submission indefinitely.
By posting your patch in a public forum rather than in private to a single developer, you create more opportunities for review and comment.
These are some of the questions developers are likely to have about your patch:
* What problem does it solve, or what feature does it add?
* Specific questions about the workings of individual parts of the patch
There's a web interface to the emc2 source. It can show you current or past versions of files, and also allows you to download tarballs of any version: http://cvs.linuxcnc.org/cvs/emc2
The source can also be viewed online in LXR, which adds hyperlink cross-references within the source code: http://cvs.linuxcnc.org/lxr/source
Historically, emc development used CVS as its source control management system. The project now uses Git.|