rcsclean

rcsclean [options] [file...]

-u
    Unlock a file if it is locked by the calling user and its contents match the latest revision in the RCS file, and then delete the working file. Without this option, rcsclean will not remove locked files.

-n
    Perform a 'dry run'. This option makes rcsclean report what it would do (i.e., which files it would delete) without actually performing any deletions. Useful for previewing changes.

-ksubst_style
    Set the keyword substitution style for text files. This works similarly to the -k option in co (checkout), affecting how keywords like '$Date$' are expanded during comparison.

-q
    Operate in quiet mode. Suppress the printing of diagnostic messages, such as those indicating which files are being deleted.

-rrevision
    Specify the revision to compare working files against. Only files identical to this specific revision (and not locked) will be cleaned. If omitted, the default is the latest revision on the default branch.

-T
    Preserve the modification time of the RCS file. Normally, checking in a new revision or performing other operations updates the timestamp of the RCS file. This option prevents that.

-Vversion
    Display the version number of the RCS system and exit.

-xsuffixes
    Specify the suffixes for RCS files. For example, -x,.v would look for RCS files ending in .v. The default is ,v.

-zzone
    Specify the time zone to use when comparing dates. This is useful when working across different time zones to ensure consistent date comparisons.

rcsclean is a utility from the Revision Control System (RCS) suite designed to remove working files that are no longer necessary in a directory. It compares the working files with their corresponding RCS files (typically named file,v) and deletes them under specific conditions.

The primary purpose of rcsclean is to help maintain a tidy working directory by removing files that have either been successfully checked in (and thus their changes are safely stored in the RCS repository) or are identical to the latest revision in the repository and not currently locked for editing. It intelligently avoids deleting files that are currently locked by the user or have local modifications that haven't been checked in yet, unless explicitly told to do so with certain options.

This command is particularly useful in environments where many files are managed by RCS, allowing developers to quickly clean up their workspace after a series of check-ins, reducing clutter without losing valuable work.

Using rcsclean with the -u option can lead to data loss if not used carefully, as it will unlock and delete files even if they contain local modifications that are identical to the latest revision in the repository. Always use -n first to preview actions, especially in unfamiliar directories. rcsclean only removes working files; it does not remove empty directories after files have been cleaned.

rcsclean operates by looking for a corresponding RCS file (e.g., file,v for a working file named file) in the current directory or in an RCS subdirectory. It then compares the working file's content and lock status with the information in the RCS file to decide whether to remove it.

A working file is deleted by rcsclean if:
1. It is not locked by any user (unless -u is specified and locked by the invoking user).
2. Its content is identical to the latest revision in the RCS file (or the revision specified by -r).

rcsclean is an integral part of the original Revision Control System (RCS), which was developed by Walter F. Tichy and first released in 1982. RCS was one of the earliest widely adopted version control systems, primarily designed for managing individual files rather than entire projects. rcsclean's functionality has remained largely consistent since its inception, reflecting its core purpose of local working file management within the RCS paradigm. While newer, more distributed version control systems like Git have become prevalent, RCS and its utilities like rcsclean are still found in legacy systems and in environments where simple, file-based version control is sufficient.

ci(1), co(1), rcs(1), rcsdiff(1), rcsmerge(1)