The logging of changes also allows changes to be "rolled back" to previously stable versions, so you can modify a working set of files without having to worry about keeping manual backups. Keeping track of different people's modifications to a collaborative piece of work is almost impossible without automatic versioning, so it can be invaluable for any group project, including software development, web design and column writing.
When editing a file stored in RCS, a lock file is created to prevent others from modifying the file at the same time and overwriting the edits made. In CVS, on the other hand, many people can edit a file at the same time, and they can all merge their changes into the file when they finish editing. When conflicting edits are made, they must then decide which edits to keep and which to discard.
RCS works by the concept of checking out and checking in files. When you first create a file, you check it in to add it to the RCS controlled system. When you want to edit the file, you can check it out and lock it. This prevents other people from checking out the same file and overwriting any changes you're making. When you're done editing the file, you check it in and unlock it, and only at that point can anyone else check it out to add their own modifications.
To check files in and out, you use the
ci (check-in) and
co (check-out) commands. For example:
co -l filename
ci -u filename
rlogallows you to view the RCS log and see the list of changes that have been made. For example:
You can see here that the file intro.html has been checked in 3 times, twice by user kchen, and once by user aerynne. The comments sumamrizing the changes that they typed upon checkin are shown as well.
athena% rlog intro.htmlRCS file: RCS/intro.html,v Working file: intro.html head: 1.3 branch: locks: strict access list: symbolic names: keyword substitution: kv total revisions: 3; selected revisions: 3 description: ---------------------------- revision 1.3 date: 2004/01/04 21:14:02; author: aerynne; state: Exp; lines: +1 -1 Guillotined an erroneous comma. ---------------------------- revision 1.2 date: 2004/01/04 05:03:34; author: kchen; state: Exp; lines: +1 -1 added MIT's ---------------------------- revision 1.1 date: 2003/12/29 04:37:46; author: kchen; state: Exp; Initial revision =============================================================================
You can also use
rcsdiff to see what changed between two
versions of the file. The -u option is often useful, as it displays
not only the lines that were changed but also the lines surrounding
those lines to provide context for the changes.
athena% rcsdiff -r1.1 -r1.2 -u intro.html=================================================================== RCS file: RCS/intro.html,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- intro.html 2004/01/02 03:27:57 1.1 +++ intro.html 2004/01/04 05:03:34 1.2 @@ -1,3 +1,3 @@ Deluged with spam? In this column, we revisit the topic of spam filtering with SpamAssassin, and discuss the new changes made to -SpamAssassin's configuration. +MIT's SpamAssassin configuration.
rcsdiffshows the change made between versions 1.1 and 1.2 of the file. The line "SpamAssassin's configuration" was removed, and "MIT's SpamAssassin configuration" was added.
C-x v v. When checking in a file after the first time, Emacs will open a buffer prompting you to enter a change comment. After entering your comment, C-c C-c will end your comment and check the file back into RCS.
Good luck on your final projects and exams! If you have any questions or comments over the summer, or any other time, feel free to e-mail us at email@example.com.