Revision Control System (RCS) Frequently Asked Questions (FAQ) Distributed as Free Documentation Copyright (c) 2003, 2004, 2005, 2007 Aaron Hawley Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, with one Front-Cover Text: "Distributed as Free Documentation", and one Back-Cover Text: "Support Free Documentation by reading and helping write Free Documentation". A copy of the license entitled "GNU Free Documentation License" is not included, but is available at . 1. When using RCS I get error or warning messages concerning diff, how do I quiet them? First, make sure to use the GNU diff utilities package, and have it configured properly. If not, then RCS will behave unreliably and some features of RCS will not be available. 2. When using RCS I have problems with binary files? Make sure the GNU diff utilities package is installed. It provides the implicit binary file support for RCS. Any problems arising from diff's binary file support should be directed to the GNU diffutils package. However, if binary file support with diff is functioning properly, then the problem is likely related to how RCS is interacting with diff. The problem is more likely associated with RCS having been built and installed incorrectly and is now causing RCS to use the native system's diff commands (which may lack binary file support) rather than GNU diff. On some systems and builds of RCS, an RCS file needs to be initialized as binary before the initial commit with: rcs -i -kb FILE ci FILE 3. How do I specify for RCS the path to the diff command? If RCS is not using the diff command supplied with GNU diffutils, or the path to the diff of GNU diffutils has changed, then you need to reconfigure and rebuild RCS using the correct path to GNU diff. 4. I'm having a problem with a specific file. You didn't ask a question. Send the file to others to inspect. Preferably send it to those who are wise in the ways of maintaining the RCS package. They can attempt to duplicate the behavior and verify what is wrong with the file. 5. How do I build RCS as non-root user after downloading it as a super user? During the install RCS's build system will complain about configuring and compiling RCS with the root or any other super user account: ./conf.sh: testing permissions ... ./conf.sh: This command should not be run with superuser permissions. However, attempts to correct this will give the following message: /bin/sh -x ./conf.sh 3>&1 >a.h 2>conf.err sh: a.h: cannot create *** Error code 1 make: Fatal error: Command failed for target `conf.h' This is likely because the files were unpacked by a super user account. These files will be owned and modifiable only the the super user account. This will cause file permission problems. Move the tarball to somewhere in the home directory of the non-root user that will build RCS. Make sure the proper ownership and permissions of the tarball are provided to the non-root user. With the non-root user account, unpack the tarball again, configure and build RCS. 6. I'm having a problem using RCS in Microsoft Windows(Trademark). That was also not a question. Problems or bugs found in RCS binaries build should be directed to the individual(s) who built them. They would be most capable of resolving issues. Problems in the Windows (Win32 or Lose32) environment are largely attributed to differences between the DOS file system and the POSIX-compliant file systems, and the weak command line support in Windows. For instance, RCS doesn't have support for wildcard file globbing internally, this is left to the command shell. Remedy this situation by using an adequate shell, like GNU Bash . Those interested in increasing portability of RCS's program source code are encouraged to so. 7. Why is RCS not working properly with some application that utilizes it for version control? Users of applications which use RCS internally for version control are encouraged to contact the developers or support providers of the larger application, and not request help from GNU RCS support providers or developers. Maintainers and support providers for RCS are not likely to be the optimal source of information for troubleshooting RCS's functionality with another application. The developers of applications combining RCS are encouraged to request help or submit problems with RCS directly to RCS support channels, however. 8. Where is the most recent stable release of RCS available from? Information on getting the 1995 release of version 5.7 of GNU RCS is available at: http://www.gnu.org/software/rcs/ 9. Where are Windows(Trademark) versions of RCS available from? Information on getting the sources or binaries of RCS, for a variety of platforms, is available at: http://www.gnu.org/software/rcs/ Also consider getting a binary from the Cygwin system, more information at: http://www.cygwin.com/ 10. How do I make the head revision (the last revision on the main branch) from an older revision? Intricate question, but a reasonable one. For those still confused, it is customary for an individual to edit a file and save revisions in RCS in a linear (without branches) manner with a sequence like 1.1, 1.2, 1.3. It is also reasonable to decide that the most recent revision, 1.3, was wrongly created, and that one would rather start from 1.2 again, but want to keep the 1.3 revision as a precaution. The semantically correct branch pattern and delta-minimizing solution would move the 1.3 revision to a branch on 1.2, making it revision 1.2.1.1. This would be accomplished by checking out a working copy of 1.3 into the current directory, and subsequently removing its revision from the RCS file with rcs -o. Then, checking the working file (what was revision 1.3) as a branch to 1.2 (for example 1.2.1.1). All revisions to 1.2 will now progress on the main branch replacing 1.3 and continuing on with 1.4, 1.5 and so on. The command recipe for this solution would look something like the following: co -r1.3 -u file # check out an unlocked version of 1.3 rcs -o1.3 file # remove version 1.3 from the RCS file rcs -l1.2 file # get a lock on 1.2 so we can make a branch ci -r1.2.1 file # create a branch from 1.2 with what was revision 1.3 Unfortunately, this solution generates two problems about revision accuracy and user difficulty. The former problem stems from the original revision information (date, author, comments) not being preserved by the "move". Moving a revision is difficult for beginners and is complicated by having to use the revision deletion operation and re-entering the previous comment. An alternative solution that isn't semantically correct nor delta-minimizing could be easier and more intuitive for users. The solution would check out a working copy of 1.2, then request a lock for revision 1.3, then have changes made to 1.2 checked in as 1.4. The recipe for this solution looks something like the following: co -u1.2 file # get a working copy of 1.2 rcs -l1.3 file # lock the head edit file ci file # check-in on main as (as 1.4) It should be clear that this is not semantically correct because the 1.3 revision is not actually an intermediate revision between revision 1.2 and 1.4. Instead it represents an experimental branch of 1.2 and was never part of the linear development of the file. Arguably, the user really reverted to revision 1.2 and started it as 1.4. However, this inaccurate history of the file creates a problematic scenario for the actual revisions stored in RCS. The reverse deltas--how RCS physically stores revisions--in this scenario for the file revisions from 1.2 to 1.4 could be pictured as this: [Full Copy of 1.4] -> [Difference from 1.3 to 1.4] -> [Difference from 1.2 to 1.3] -> ... RCS keeps the most recent revision in its entirety, and maintains the changes--also called deltas or differences or just diffs--to construct previous revisions 1.3, 1.2 and so on. In our scenario of resurrecting the 1.2 revision as 1.4, the "Difference from 1.3 to 1.4" contains the reverse delta of changes that are used in 1.4, changes that aren't used in 1.4 and the differences between 1.2 and 1.4. Here's a representation of the reverse deltas with this considered: [Full Copy of 1.4] -> [Differences from 1.2 to 1.3 that weren't used in 1.4 Differences from 1.2 to 1.3 that were used in 1.4 Differences from 1.2 to 1.4] -> [Changes from 1.2 to 1.3] -> ... Here is what the reverse deltas would be if the first proposal was used where the 1.3 revision was made a branch of 1.2: [Full Copy of 1.3] -> [Difference from 1.2 to 1.3] -> [Difference from 1.2 to 1.2.1.1] -> ... The full copy of the 1.3 head revision has a delta to 1.2, and then the 1.2 revision has a branch to revision 1.2.1.1. The delta tree is much cleaner and representative of the changes to the document. 11. Does RCS support an obscure file type I have? The programming design philosophy of the GNU Project, which by association GNU RCS must also follow, requires programs to be written robustly and "avoid arbitrary limits on the length or number of any data structure" (Stallman et al. "GNU Programming Standards". Section 4.1. On the Internet: . Last modified: February 21, 2004. Last visited: May 25, 2004.) Therefore, large files (unless physical limits are otherwise noted) are supported. RCS supports both text and binary files by virtue of using GNU diffutils which does the work necessary for creating reasonable "deltas" between different versions of a binary file (See Question 2 above). 12. How do I keep RCS from inserting carriage returns upon check-in (ci) in my files I have on a unix-flavored operating systems? A carriage return or "CR" is ASCII decimal value 13, ASCII octal value 015, ASCII hexadecimal value 0d, is represented by the ASCII escape (backslash) sequence "\r" and is displayed in Unix terminals as "^M". To prove that an installation of RCS is errantly inserting carriage returns at the end of lines and is not related to the specific files that are being checked-in, try running this unix shell script: #!/bin/sh rm rcs-cr-test.txt,v echo "first line of file" > rcs-cr-test.txt cp rcs-cr-test.txt rcs-cr-test.txt~ ci -t-'Test of carriage returns in RCS' rcs-cr-test.txt mv rcs-cr-test.txt~ rcs-cr-test.txt # echo -e "first line of file\r" > rcs-cr-test.txt ## The above line is what the bug is inducing and attempts ## to mimic the behavior on systems without the bug rcsdiff rcs-cr-test.txt If the check-in (ci) command is inserting carriage returns, the output should look something like the following: rcs-cr-test.txt,v <-- rcs-cr-test.txt initial revision: 1.1 done rcsdiff -r1.1 rcs-cr-test.txt 1c1 < first line of file --- > first line of file^M If the above is the case, then report the situation to the authorities. But if the output looks like this: rcs-cr-test.txt,v <-- rcs-cr-test.txt initial revision: 1.1 done rcsdiff -r1.1 rcs-cr-test.txt then the problem is not reproducible. Instead, investigate if edits were made to the interested files on an operating system (notably either the Windows(Trademark) and Macintosh platforms) that inserts carriage returns at the end of lines of text. 13. How do I resolve the error "RCS file foo is in use"? Remove the file that is called ",foo,". As the "BUGS" section of the RCS manual reads: A catastrophe (e.g. a system crash) can cause RCS to leave behind a semaphore file that causes later invocations of RCS to claim that the RCS file is in use. To fix this, remove the semaphore file. A semaphore file's name typically begins with , or ends with _. -- Support free documentation by reading, writing, copying, publishing, helping, supporting, citing and purchasing free documentation. $Id: faq.txt,v 1.19 2008-04-01 01:39:03-04 ashawley Exp $