[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A less invasive rcs

From: David Levner
Subject: Re: A less invasive rcs
Date: Wed, 24 Feb 2021 14:48:00 +0000 (UTC)

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

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/ and later decide to create a lib/Some directory
and rename the file to lib/Some/ 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.

John Yates and Dario Niedermann wrote:

>I propose a third location, a mirror of that working directory
>located by searching upward, through parent directories, for
>a "dominating" .rcs directory.

Personally, I like to have the RCS directory in foo/ to be a symlink
to /usr/local/share/RCS/foo; and the RCS directory in foo/bar/ as a
symlink to ../RCS/bar .

Doesn't this look like what you're trying to achieve?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]