files in Repository CVSROOT directory
easiest way to look at them is to check them out like a normal cvs project (cvs co CVSROOT)
look at files in order of importance
config
allows you to configure certain global behavior parameters
you can give alternative names for a project and sub directories of it:
mp myproj
asub myproj/a-subdir
with this in the modules file, the following commands would be valid:
cvs co mp
cvs -d repository_directory co asub - for checking out a subdirectory of the project
when checking out files with this method, the folder that is checked out to will be given the aliases name, and not the full original name of the folder
you can also define modules containing only certain some files in a particular directory:
readme myproj README.txt
no-readme myproj hello.c foo.jpg
When checkinjg out readme you will get only the readme file, and no-readme will give youu hello.c and foo.jpg, but no readme, even though all three files existed in the same folder in the repository
You can create an alias to refer to multiple modules with one name:
twoproj -a myproj yourproj
would cause cvs co twoproj to checkout myproj and yourproj and put them in their own respective directories. (not in a directory called twoproj)
Aliases don't have to refer to multiple projects
modules can refer to other modules (prefix module name with ampersand):
tp &twoproj
more information see “Modules” in Cederqvist
commitinfo and loginfo
generally follow the form:
REGULAR_EXPRESSION PROGRAM_TO_RUN
commitinfo is for generic programmatic hooks you want to run on every commit.
for example:
^a-subdir* /usr/local/bin/check-asubdir.sh
ou /usr/local/bin/validate-project.pl
commits can only match once, so rules should be placed in the order of priority, the fist match will eliminate all other matches possible in the file.
In place of a regular expression the word DEAFAULT or ALL can be used. The first DEFAULT line in the file will be run in the event of no matches, and all ALL lines will be run in addition to any other matches that occurred in the file.
The loginfo file works basically the same as commitinfo except that instead of acting on file's contents, it acts on the log message. The prgram run will be passed the log message on it's standard input. You can also pass it an arbitrary number of command line arguments.
one of the arguments can be a special “%” code for cvs to expand at runtime:
%s -----------> name(s) of the files being committed
%V -----------> revision number(s) before the commit
%v -----------> revision number(s) after the commit
expansion always begins with the path to the repository followed by the requested information
example output:
%s:
myproj foo bar baz
%V:
myproj 1.7 1.134 1.12
%v:
myproj 1.8 1.135 1.13
There can only be one % expression per line so if you want to include more than one include them in curly quotes (%{sV}) results will be the path to the repository followed by a comma seperated list of results.
for example:
%{sv} might become:
myproj foo,1.8 bar,1.135 baz,1.13
%{sVv} might be:
myproj foo,1.7,1.8 bar,1.134,1.135 baz,1.12,1.13
sample login file:
^myproj$ /usr/login/cvsrep/CVROOT/log.pl -m myproj-devel@foobar.com %s
ou /usr/local/bin/ou-notify.pl %{sv}
DEAFAULT /usr/local/bin/default-notify.pl %{sVv}
The first line invokes log.pl and gives it an e-mail address (to which it will send an e-mail containing the log message) followed by the repository and then all the files in the commit. (-f filename can be used to make a log file of commit log messages)
The next two lines call imaginary files and I'll skip explaining them.
verifymsg and rcsinfo
The verifymsg follows the regular expression - program format of the last section. The rcsinfo file has a regular expression on the left side while the right side points to a template file.
A template file should be a list of fields that a developer is supposed to fill out to create a valid log message. If developors commit with the -m option them the rcsinfo file isn't used. When a developer runs cvs commit however, the template is inserted in the text editor for the developer to fill out.
When the user commits, the appropriate program in verifymsg is invokes, presumably to check that the message follows the appropriate format. Success is indicated with a '0' status. I'm not sure if an -m commit will activate the verifymsg file, but the fact that the path to the template from the rcsinfo file is appended as the last argument to the program command line in verifymsg so that the program can base it's verification process on the template itself, gives me the feeling that it won't.
In the verifymsg file, the ALL keyword is not supported, but DEFAULT is.
taginfo
taginfo files follow the regular expression - program format, and do for tags what loginfo does for logs. Programs invoked by taginfo are handed argument in this order:
arg 1: tag name
arg 2: operation ("add" => tag, "mov" => tag -F, "del" => tag -d)
arg 3: repository
arg 4, 5, etc: file revision [file revision ...]
If the program, returns a nonzero result, the tag is aborted.
the -F option to tag is a way to move a tag from one revision to another.
for example, to move the tag "Known_Working" from revision 1.7 to revision 1.11:
cvs tag -r 1.11 -F Known_Working foo.c
cvswrappers
Is a way to specify that certain files should be treated as binary, based on their file name.
I think this is a very useful thing to know for web designers
here is a line to specify that .jpg files are all binary:
*.jpg -k 'b'
The 'b' is seperate and in quotes because it is not the only possibleRCS keyword expansion mode. One could also specify 'o' which means not to expand $ keywords but to do newline conversion. for more nodes see “Wrappers” in Cerqvist.
editinfo
obsolete
notify
will cover later
checkoutlist
This is for adding extra files, such as programs or rcsinfo templates into the CVSROOT directory, and have them treated as administrative files. (You can then check them in and out like other projects) When commiting new or modified administrative files you will get an extra line at the end of the commit that looks like this:
cvs commit: Rebuilding administrative file database
The format of the checkoutlist file is:
FILENAME ERROR_MESSAGE_IF_FILE_CANNOT_BE_CHECKED_OUT
for example:
log.pl unable to check out / update log.pl in CVSROOT
bugfix.tmpl unable to check out / update bugfix.tmpl in CVSROOT
the history file is not included in this system. It is used for the cvs history command. If you remove it cvs will stop keeping a log of all repository actions.
The passwd fiule is also not included in the check out list by default. It can be added if you don't think that it is a security risk.
If something goes badly enough wrong that commits can't take place at all, you will have to go in and hand edit the repository's working copy of the administrative file.
For security's sake, it is important to make sure that your CVSROOT directory is writable only by users you trust. People with access to these files can run programs on your machine.
Creating a Repository
cvs -d repository_directory init
NOTE: repository directory needs to exist before you can turn it into a repository (probably)
The CVSROOT directory inside a repository contains administrative files that control CVS' behavior.
For security reasons it is highly recommended that you set up a cvs group and add any users that will be accessing the repository.
To do this in Mac Os X, open netinfo, go to the groups folder, click on a group and duplicate it. Change the name of the copy, the group id, and set up the users to be included, then save it.
You will then need to setup you repository folders to those permissions.
cd repository_directory
chgrp -R cvs .
chmod ug+rwx . CVSROOT
when adding a new project or files or folders you should probably chgrp -R cvs folder them.
Tip o ' Tod [ BSD systems (including Mac OS X) automatically assign the parent directory's group to sub directories and files inside them. This means we don't need my comment above. For Linux systems we can avoid the chgrp step above by doing this in advance:
chmod g+s path/to/repository]
If you are planning to run a publicly accessible repository, you should set up a Password-Authenticating Server. Since I am not doing that now, I have skipped this section.
understanding RCS Files
in repositories all files show up as filename,r
This file shows the whole text of the most recent update, and then diffs for each revision before that. When you revert to an old version say from 1.7 to 1.5, CVS applies the patch for 1.6 to 1.7 and then the patch for 1.5 to what is now the same as 1.6 was.
Repository structure
Don't use directories named Attic in CVS projects because when files are removed from the project, they will be moved there, and their revision history will be updated to say that the status is “dead.”
Bedtime for now, and I don’t feel I covered that much ground. Next Episode: The CVSROOT Administrative directory - stay tuned