cvsstat.pl - Convert 'cvs stat -v' output to revision tree notation
CVS is a version control software available at http://www.cvshome.org/. 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.
branch
revision
revision
branch
revision
revision
revision
branch
revision
revision
revision
cvsstat.pl --help
cvsstat.pl --file cvs-file.txt
cvs stat -v cvs-file.txt | cvsstat.pl
cvs stat -v cvs-file.txt | cvsstat.pl --brief
cvs stat -v directly and format
the output. This is like doing
bash$ cvs stat -v file.txt => cvsstat.pl --file file.txt
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="cvsstat.pl --file"
tcsh$ alias cvss 'cvsstat.pl --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
The cvst stat output looks like this:
bash$ cvs stat -v test.txt
File: 1 Status: Up-to-date
Working revision: 1.1.1.1.2.1 Wed Jul 24 11:37:14 2002
Repository revision: 1.1.1.1.2.1 /cvstroot/test/test.txt,v
Sticky Tag: my-1 (branch: 1.1.1.1.2)
Sticky Date: (none)
Sticky Options: (none)
Existing Tags:
b2 (revision: 1.1.1.2)
vendor-v2 (branch: 1.1.1.1.2)
b1 (revision: 1.1.1.1)
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 | cvsstat.pl
File: 1 Status: Up-to-date
Working revision: 1.1.1.1.2.1 Wed Jul 24 11:37:14 2002
Repository revision: 1.1.1.1.2.1 /cvstroot/test/test.txt,v
Sticky Tag: my-1 (branch: 1.1.1.1.2)
Sticky Date: (none)
Sticky Options: (none)
Existing Tags:
1.1.1 branch vendor-v1
1.1.1.1 revision b1
1.1.1.1.2 branch my-1
1.1.1.2 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
http://www.gnu.org/software/emacs/emacs.html releases and local changes
to the lisp modules.
bash$ cvs stat -v anther-test.txt | cvsstat.pl --brief
1.1.1 branch fsf
1.1.1.1 revision v20-6
1.1.1.1.2 branch b20-6
1.1.1.1.2.1 revision b20-6-change-one-2000-12-14
1.1.1.1.2.2 revision b20-6-change-one-2001-01-01
1.1.1.1.2.3 revision b20-6-change-one-2001-01-02
1.1.1.1.2.4 revision b20-6-change-one-2001-01-02
1.1.1.1.2.5 revision b20-6-change-one-2001-01-04
1.1.1.1.2.5.2 branch b20-6-w32-change-two
1.1.1.1.2.5.4 branch b20-6-w32-change-three
1.1.1.1.2.5.6 branch b20-6-w32-change-four
1.1.1.1.4 branch b20-6-special
1.1.1.1.6 branch b20-6-w32-input-reader
1.1.1.1.8 branch b20-6-w32-telnet
1.1.1.1.10 branch b20-6-w32-telnet
1.1.1.1.12 branch b20-6-w32-telnet2
1.1.1.1.14 branch b20-6-merge-2001-01-04
1.1.1.1.14.1 revision b20-6-merge-2000-01-07
1.1.1.1.16 branch b20-6-w32-protocol
1.1.1.1.18 branch b20-6-autosave
1.1.1.1.20 branch b20-6-w32-spell
1.1.1.2 revision v20-7-3
1.1.1.3 revision v21-1
1.1.1.3.2 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 cvsbook.red-bean.com/
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, www.w3c.org that are related>
None known.
Project home page is at http://cvs-tools.sourceforge.net/ Reach author at jari.aalto@poboxes.com
CPAN/Administrative
Only standard Perl modules used.
Only standard Perl modules used.
any
$Id: cvsstat.pl,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.