I am brainstorming some extensions to rcs that would
- Avoid both ,v files and RCS directories in working trees
- Allow the ,v files to be stored in a fully separate tree
Today, we have two places for a working file's ,v file:
- In the working file's working directory
- In an RCS subdirectory added to that working directory
I propose a third location, a mirror of that working directory
located by searching upward, through parent directories, for
a "dominating" .rcs directory. If such a directory is found, it
contains a parallel directory structure:
.../project
├── src
│ ├── foo.c
│ └── bar.c
├── inc
│ ├── foo.h
│ └── bar.h
├── doc
│ └── foo.md
└── .rcs
├── src
│ ├── foo.c,v
│ └── bar.c,v
├── inc
│ ├── foo.h,v
│ └── bar.h,v
└── doc
└── foo.md,v
How to search for a ,v file:
- Look in working file's directory
- If the working directory contains an RCS sub-directory,
then look there
- If a "dominating" .rcs directory exists, look in the
corresponding directory
Where to create a new ,v file:
- If a "dominating" .rcs directory exists, ensure existence
of a corresponding directory and create it there
- If a RCS sub-directory exists, create it there
- Create it in the working file's working directory
To provide a means of stopping the upward search for a .rcs
marker I propose a very simple .rcsstop marker.
At this point I take some inspiration from git for a separate
directory convention. This means allowing the "dominating"
.rcs marker to be a file, similar to .git. If it is a file then it is
a "file system agnostic" symbolic link to an out of tree .rcs
directory. The contents of this file is
rcsdir: <path>
Does this seem too crazy? Any implementation suggestions?
Where is the relevant search logic implemented in the rcs
source?
/john
