Another way to implement John's .rcs sub-tree suggestion is by
writing wrapper functions that invoke the rcs executables. I have
already written wrapper functions that provide some functionality
that RCS lacks, such as invoking a text editor to edit check-in
comments. (My wrapper functions run under a custom shell written
in Perl. The functions are Perl subroutines that can be invoked as
commands from the shell's command line.)
Building on the wrapper functions that I currently have, I could
implement John's .rcs idea in a couple of days (one day if I got
lucky).
My concern about the .rcs subtree is that I sometimes make changes
to my source directory structure. For example, I might create a file
lib/Something.pm and later decide to create a lib/Some directory
and rename the file to lib/Some/Thing.pm. With the RCS directories
that I currently use or a .rcs subtree, manual changes are needed.
This could be addressed by making wrappers for mv and mkdir that are
RCS-aware. I have not done this--perhaps it is not worth the extra
complexity. Perhaps there is a better solution.
Another thought is to make .rcs into a small configuration file. If it
contained the name of the root of the RCS sub-tree, then the
RCS sub-tree could go anywhere.