NAME - Convert 'cvs stat -v' output to revision tree notation


CVS is a version control software available at On of its many commands is cvs stat -v FILE which prints the revision and tag information. This program converts cvs stat -v output to a more readable revision hierarchy tree.


SYNOPSIS --help --file cvs-file.txt
    cvs stat -v cvs-file.txt |
    cvs stat -v cvs-file.txt | --brief


Gneneral options

--brief -b
Print only revision tree. Suppress header printing.

--cvs -c
Instead of reading the output, call cvs stat -v directly and format the output. This is like doing
    bash$ cvs stat -v file.txt  => --file file.txt

--file -f FILE [FILE ..]
Run cvs stat -v on FILE and then format the output. If you have operating system (non-Win32), which allows making aliases, you could do a shortcut:
    bash$ alias cvss=" --file"
    tcsh$ alias cvss ' --file \!*"

After that, these two were equivalent:

    bash$ cvs stat -v cvs-file.txt
    bash$ cvss cvs-file.txt

Remember to have this line in your $HOME/.cvsrc, which prepends always option -v to the status command.

    status -v

Miscellaneous options

--debug [LEVEL]
Turn on debug with positive LEVEL number. Zero means no debug.

Print help

Print help in HTML format.

Print help page in Unix manual page format. You want to feed this output to nroff -man in order to read it.

Run in test mode, do not actually do anything.

Print informational messages.

Print contact and version information


The cvst stat output looks like this:

    bash$ cvs stat -v test.txt
    File: 1                 Status: Up-to-date
       Working revision:     Wed Jul 24 11:37:14 2002
       Repository revision:     /cvstroot/test/test.txt,v
       Sticky Tag:          my-1 (branch:
       Sticky Date:         (none)
       Sticky Options:      (none)
       Existing Tags:
            b2                              (revision:
            vendor-v2                       (branch:
            b1                              (revision:
            vendor-v1                       (branch: 1.1.1)

As you can see, this file contains two kinds of tags (labels): branches and revisions. Conceptually the development line above can be expressed as:

    vendor-v1   (First import: "cvs import code/tree/here net vendor-v1")
    +-b1        (Branch of it: "cvs tag -b b1; cvs up -r b1")
    vendor-v2   (Second import)
    +-v2        (Branch of it)

The above is a typical situation when tracking third party changes. A user started the project by downloading vendor's software and importing it into CVS tree (vendor-v1). In order to make private changes to the code, a branch was created (b1). Later a new release appeared and the vendor code was again imported to the tree (vendor-v2) followed by a working branch for private changes (v2).

Now, as the development continues, there will be many more branches and imports and soon it will be hard to grasp how does the development tree look like. The obvious question it: what tags should I use to merge the changes forward when I don't understand the revision hierarchy? In order to make the decisions, this script will help by converting the output to more readable format. Like this:

    bash$ cvs stat -v test.txt |
    File: 1                 Status: Up-to-date
       Working revision:     Wed Jul 24 11:37:14 2002
       Repository revision:     /cvstroot/test/test.txt,v
       Sticky Tag:          my-1 (branch:
       Sticky Date:         (none)
       Sticky Options:      (none)
       Existing Tags:
             1.1.1 branch vendor-v1
      revision b1
        branch my-1
      revision vendor-v2

A more complicated tree layout would look like below. Here the vendor code (fsf) has been imported 3 times with release revision numbers: 20.6, 20.7.3 and 21.1. Since tag name cannot contain dots, dashes were used instead. If the revisions look familiar to you, they are Emacs releases and local changes to the lisp modules.

    bash$ cvs stat -v anther-test.txt | --brief
         1.1.1 branch fsf
  revision v20-6
    branch b20-6
      revision b20-6-change-one-2000-12-14
      revision b20-6-change-one-2001-01-01
      revision b20-6-change-one-2001-01-02
      revision b20-6-change-one-2001-01-02
      revision b20-6-change-one-2001-01-04
        branch b20-6-w32-change-two
        branch b20-6-w32-change-three
        branch b20-6-w32-change-four
    branch b20-6-special
    branch b20-6-w32-input-reader
    branch b20-6-w32-telnet
    branch b20-6-w32-telnet
    branch b20-6-w32-telnet2
    branch b20-6-merge-2001-01-04
      revision b20-6-merge-2000-01-07
    branch b20-6-w32-protocol
    branch b20-6-autosave
    branch b20-6-w32-spell
  revision v20-7-3
  revision v21-1
    branch b21-1-merge-2000-01-15

If your're wondering how you would keep track of 3rd party software easily (easier than that of above), here is simple procedure. The vendor tag chosen here is net for all the code that you download from Internet. You could use tags like fsf, apache, sun etc., but it's easier to stick one name that covers them all: the net.

    1. Unpack to fresh place. Go to unpack directory
        cvs import -m "version 20.6" code/dir net v20-6
    2. Check out fresh copy
        cvs co -d v20-6 code/dir
    3. Prepare you local changes by creating a branch
        cvs tag -b b20-6
    4. Change to branch and start working with your local changes
        cvs up -r b20-6

When new release appears, re-iterate from point (1). The only thing left is to move your changes to the latest release. After step (4), you simply need join:

       cvs up -j b20-6

This assumes that you never go back to 20.6 and change it's code any more. If you need to do that, then things get much more ocmplicated and you have to tag file before the merge and after the merge. Uhm, that's another story. Refer to on-line CVS book at


See program call conventions.


Use --debug to pinpoint the problem. If you the output does not make sense, copy cvs stat -v output and send it to the maintainer with your comments.


No environment variables used.


No files created.


cvs(1) cvsweb(1) rcs(1)


<RFCs, ANSI/ISO, that are related>


None known.


Project home page is at Reach author at




Only standard Perl modules used.


Only standard Perl modules used.




$Id:,v 1.2 2002/07/27 07:39:27 jaalto Exp $


Copyright (C) 2002 Jari Aalto. All rights reserved. This program is free software; you can redistribute and/or modify program under the same terms as Perl itself or in terms of Gnu General Public license v2 or later.