This document describes the Concurrent Version System (CVS) usage and
Internet CVS documentation, manuals, a good presentation, and for the impatient a FAQ.
setenv CVSROOT ":pserver:repo.intra.blender.nl:/home/cvs" echo "====> CVSROOT set to $CVSROOT"And do a
cvs loginonce. This will create a
~/.cvspassfile with your encrypted password.
setenv CVSROOT ":ext:repo.intra.blender.nl:/home/cvs" setenv CVS_RSH "ssh" echo "====> CVSROOT set to $CVSROOT"Note: when you do not want to use SSH, use RSH. Note also that RSH is not available from the internet as it is insecure.
For RSH, add a
<yourhost>.intra.blender.nl <usercode>line in your
~/.rhostsfile, and perform a
For SSH, set it up first, this is not yet documented. But when you have ssh-agent forwarding working, nothing more is required :-)
update -d diff -u cvs -qwhich gives some default parameters to the 'cvs update' and 'cvs diff' commands. 'update -d' is important, 'diff -u' is a matter of taste, 'cvs -q' causes cvs to be somewhat less verbose.
cd ~ mkdir develop cd develop cvs co source cvs co lib cvs co intranetPlease note that you only have to do this ONCE !
The `cvs co' (check-out) will create your own source and intranet web pages working directories. It contains directories called CVS where some CVS administration is done, never change these CVS-directories or the files in them if you do not know what you're doing!
When you have finished editing you can commit your changes to the general repository with
cvs commitThis command can be given at top-level (~/develop) or at a lower level; it will always do all subdirectories too, unless explicit file names and/or directory names are given as parameters after `cvs commit'. This is the behavior for (almost) all cvs commands.
Please be careful with commits, use
cvs updatefirst to find out which files would be committed when you would do a 'cvs commit'
You will be asked to describe your changes; as editor the editor mentioned in the environment variable `EDITOR' will be used (default vi, override in your .login file if necessary). All lines in the commit template file starting with `CVS' are removed automagically from the final commit message and are only for reference purposes. Format your commit message such that the line length is less than 72 characters; exceptions are made for cut'n'paste'd lines of logfiles/programs.
After you have described your changes save the file and exit the editor. A commit message will be mailed to the development group. When committing many files at once in different directories it is possible to use one description for all changed files by answering '!' at the appropriate question.
Do not wait too long (i.e., days or weeks) before committing your changes, because otherwise somebody else may have changed the files which could lead to CVS conflicts. If you are uncertain whether you have the latest version you can always use
cvs updateThis will resynchronize your development tree and the repository. Also watch commit mails from other developers to see if they are working in the same area which could lead to conflicts.
To view the differences between your (changed) working copy of a file and the last version in the repository use:
cvs diff filenameFor better readable output use a `-u' option after `diff' (can also be stored in your
~/.cvsrc). cvs diff also works for directories and without any further arguments it show the differences of all files in the current directory and all directories below it.
New files/directories can be added with
cvs add filename cvs add directorynameThen, an explicit
cvs commitis necessary to really add the file to the repository; for directories it is done (and mail is sent) automatically.
Binary files must be added with
cvs add -kb binary_filenameThis can still be done afterwards with
cvs admin -kb binary_filename
Note that one cannot use 'cvs add *' because the 'CVS' directory itself will then be added as well.
Private develop server:
rm filename cvs delete filenameAn explicit `cvs commit' is necessary to really delete the file from the repository. (Well, ok, move to the 'attic' ;-) not really delete)
The full revision history of the file will be kept.
=================================================================== File: cvs.html Status: Locally Modified Working revision: 1.18 Wed Apr 22 15:17:30 1998 Repository revision: 1.18 /home/cvs/intranet/conventions/cvs.html,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none)The 'Sticky' things should normally be '(none)', unless development branches are created. 'cvs status' also works for directories and can be used without arguments so it shows the status of a whole directory tree.
To view the history of a file use 'cvs log filename'. Example:
RCS file: /home/cvs/intranet/index.html,v Working file: index.html head: 1.5 branch: locks: strict access list: symbolic names: keyword substitution: kv total revisions: 5; selected revisions: 5 description: ---------------------------- revision 1.5 date: 2000/03/08 13:47:25; author: hans; state: Exp; lines: +3 -3 fix telephone link ---------------------------- revision 1.4 date: 2000/03/08 09:58:21; author: hans; state: Exp; lines: +4 -4 add link to cvswebRCS is the underlying mechanism for CVS. Times are logged in UTC (GMT).
You'll find something like :
todoThen do for each file listed a diff from the previous version to the one listed :
cvs diff -uw -kk -r1.6 -r1.7 source/a/b/Makegile cvs diff -uw -kk -r1.5 -r1.6 source/a/c/source.cNote 1 : if the file originates from a vendor branch you might want to replace the first -r revision with the vendor branch revision. You then use something like :
cvs diff -uw -kk -r220.127.116.11 -r1.6 source/a/vendor/othersource.cNote 2 : you might want to use the symbolic version name if you want to diff against the vendor branch. You then use something like :
cvs diff -uw -kk -rV2_3_3 -r1.7 source/a/vendor/othersource.cNote 3 : when you want to diff everything against the latest vendor branch, do something like this:
cvs diff -uw -kk -rV2_3_3
find . -name CVS -print | xargs rm -fr find . -name RCS -print | xargs rm -fr
chmod -R +r *
cvs import extern/python/distribution PYTHON V1_5_2And change python in the appropriate vendor module name, PYTHON in the appropriate vendor module name, V1_5_2 in the appropriate version (replace . with _)
NOTE: paste the 'cvs import' line in your commit mail, it is an excellent place to log the used vendor module name.
cd ~/develop/extern/python/distribution cvs update
cd ~/develop/extern/python/distribution cvs update -jV1_5_2 -jV1_5_3
cd ~/develop/extern/python/distribution cvs diff -rV1_5_3
cd ~/develop/extern/python/distribution cvs commit
There are two solutions, one that deals with cvs surgery and one that does not which we show first :
To revive a file which was removed by a 'cvs delete', move the file from the 'original-directory'/Attic directory in the CVS repository to the directory above. Then use 'rlog file,v' to get the latest revision number (let's say it is X.Y), the 'state:' for that revision will be 'dead'. Revive the file using the following command:
rcs -sExp:X.Y file,vAfter this a 'cvs update' in your own working directory should make the file reappear.
Tags are needed anyway if we decide to start using branches (needed when we want a development branch next to a patches branch after a new release was made) (I hope we can postpone this branching, it is quite complicated)
We use the following naming standard:
blender-creator-<version numbers>-release blender-publisher-<version numbers>-betawith <version numbers> the number from the VERSION file with the '.' replaced with '-'. Example for a whole tree like develop/source, develop/lib, develop/release :
cd ~/develop/source/ && cvs tag blender-creator-2-22-releaseThe release manager will be the one performing these tagging actions.
Sometimes the maintainer of a product changes, in that case it is nice if we can rename the vendor branch accordingly.
cd distribution cvs admin -nNEW_NAME:1.1.1 . cvs admin -nOLD_NAME .The vendor tag name will now appear at the top of the symbolic names listing in 'cvs log'.
Note: we assume that 1.1.1 is the vendor branch.
Here we describe how a branch can be created.
cd ~/develop/source cvs tag NEWBRANCHNAME *.mk 174
cvs tag -b NEWBRANCHTAG *.mk 174