The following are hints and tips for using CVS.. ------------------------------------------------------------------------------- The definative manual... Version Control with CVS http://www.cvshome.org/docs/manual/cvs.html ------------------------------------------------------------------------------- Repository Setup This setup proceedure is relativally new, or performed for you by a centerial CVS administrator. As such almost all the quick help guides do not explain this, resulting in stange misleading errors on almost every CVS command a begineer trys to perform. Not only that, "init" is NOT listed in the on line manual! setenv CVSROOT /home/duty/cvsroot cvs init ------------------------------------------------------------------------------- Initial Project Submition. If you have a clean source area you want to put under CVS control, this is easy and well documented... cd {sources} cvs import {module} V1 R0 Note module is usally the same and the directory name. But if you only want parts of a source area put under CVS control, OR most of the source area is full of generated files (like object files). you may instead like create a empty CVS project, and later (see below) add individual files to CVS control. Create a empty CVS project... mkdir t; cd t cvs import {module} V1 R0 cd ..; rm -r t OR mkdir $CVSROOT/{module} At this point you can checkout this project into your existing source directory {assuming it is the same name as the module}. This will create a "CVS" sub-directory which holds information about this directory. Things like: The CVSROOT used (in which case your environment variable CVSROOT is no longer used or required); and module name/sub-directory, and version number currently checkout in this directory. Checkout the currently empty module... cd {directory above real source area - named {module} } cvs checkout {module} # ignore the errors cd {module} You can then add and commit the individual files and directoryied to the new CVS project module. You can now add directories cvs add {sub_directory} cd {sub_directory} and source files to the repository vi {source_file} # and a $Id$ comment to the file cvs add {source_file} cvs commit {source_file} ALTURNATIVE to above using tkcvs GUI interface... * run tkcvs * set file browser to parent directory of the source tree * start module browser * file -> create directory {module} {descriptive name} * "checkout" the module (ignore existing files errors) * in file broswer enter sub-directory and start add/commit of files you want to add to the CVS repository by highlighing files and directories and using the appropriate button along the bottom of window. FINISH by adding this module to the CVS modules file.. The "modules" file is checked out and updated like any other CVS file cvs checkout CVSROOT/modules cd CVSROOT Now edit "modules" and add... (Note tabs between fields) #D {module_dir} #M {module} {verbose name of this module} {module} {module_dir} The commit fileds are required for correct working of the modules browser in tkcvs. Now commit the "module" file and clean up. cvs commit -m "added the {module} module" modules cd .. cvs release -d CVSROOT rm -rf CVSROOT ------------------------------------------------------------------------------- Removing Files from Repository OR deleting add/commits which you did not mean.. To remove files from the cvs module... rename or delete {source_file} cvs remove {source_file} cvs commit {source_file} At this point the RCS delta file for that file was moved in the CVSROOT to a sub-directory "Attic" so that it can be recovered later, if needed. Delete those delta's to remove completely. THIS SHOULD NOT NORMALLY BE DONE. This should only be used to remove mistakes made during the initial add/commit sequence above. If the file is part of a previous revision or release of the software, LEAVE IT IN CVS so it can be recovered if needed. ------------------------------------------------------------------------------- When you are finished with a working directory. Release it!!! cvs release -d {module} rm -rf {module} ------------------------------------------------------------------------------- Remote access to a CVS repository First you should be able to access the machine with the repository either though RSH or SSH without a password (unix to unix), or you will need special previliges to be able to setup some sort of cvs server (not covered here). NOTE: Here at Griffith University "gucis" is only accessable via RSH (and the use of ".rhosts" files) from inside the university. SSH however can be setup to access from both inside and outsid ethe university. See the document "ssh_howto.txt" in this directory. Access using CVS's internal builtin RSH command... setenv CVSROOT :server:user@host:/path/to/repository/cvsroot To use an external RSH command (on your command path) setenv CVSROOT :ext:user@host:/path/to/repository/cvsroot To use SSH just use the above but set setenv CVS_RSH ssh and if nessary prime your ssh passphrase ssh-add (type passphrase) Using Source forges repository??? -- to be checked setenv CVSROOT username@cvs.tkcvs.sourceforge.net:/cvsroot/project setenv CVS_RSH ssh ------------------------------------------------------------------------------- Tag CVS files Revision Numbers: The editing increment or "patch" number Release Number: The Logical version number used such as when you release the software to the world. Why? The revision numbers in a CVS repository are basically edit increments and will rarely reflect the software release number. Not only that each file will have a completely different revision number to the other files at the same level of development. You can increment the major revision number at appropriate points, but this may not reflect the real release number. Tags provide a way to name all the files at a particular development level, regardless of the number of edits a particualr file has undergone. (EG: "All these files form the stable release of version 1.4") Unfortunatly CVS will NOT allow you to use "dots" in a tag name. If it sees a "dot" it takes this to mean you are providing a revision number, and not a tag name. As such tags usally use dashed `-' and underscores '_' instead of dots for the tag names in the CVS repository. EG: rel-1_4 or rel-1_1-patch To tag the current point (in the repository not your working copies) cvs tag {tag_name} To move an existing tag, say to mork the latest stable release... cvs tag -a -r rel-1_6 -F stable The -r specifies the revision/tagname to assign the tag "stable" to. The -F relocates the existing tag to that revision/tagname. and the -a incluced taging any now deleted files, that were undeleted at that time. ------------------------------------------------------------------------------- CVS branches CVS creates side branches by tagging them. You must name a branch cvs rtag -b -r {revision to branch from} {branch name} Eg: cvs rtag -b -r rel-1_3 rel-1_3-patch The revision numbers of each file on the branch becomes 4 numbers (the original revision number, the branch number, and the current file revision increment. To merge a branch back into the main trunk First NAME the current top level of the branch. This will allow you to continue the development of the branch later, and re-merge the new changes to the mail trunk. EG: cvs tag Checkout main trunk {OR update all your files to the main trunk} cvs checkout Then join all the changes to the main trunk cvs update -j {branchname} cvs commit -m "merge {branchname} onto main trunk" To merge multiply you must only merge the changes from the previous merge. See section 5.7 of the "Version control with CVS" for details. I hope you remembered my warning above abount naming the last point you merged! -------------------------------------------------------------------------------