|Consider using Subversion|
If you have SSG projects and are planning to use CVS for version control, please consider using Subversion instead. The SSG software development team already has several projects under Subversion, uses it for new projects, and recommends it for version control. We will be able to assist you in the process if you would like your source code managed by Subversion.
- Read What is version control in the Pragmatic Version Control book.
- Read A Day with CVS in the free CVS book. See resources below.
- Install CVS
- Check if your IDE already has it integrated, most do.
- On Windows, you also have the following options TortoiseCVS, WinCVS, jCVS, SmartCVS, cygwin
- Get an account on the CVS server. Use the name cvs.ssg.uab.edu to access our main CVS repository.
- Set up and test ssh login (see SshNotes)
- Define CVSROOT and CVS_RSH
- Test it by checking out an existing module
- For example, 'cvs checkout hdbstat/client'
- You're all set!
Example Environmental Variables for our CVS repository
Importing an existing project
cvs import -m "log msg" projname vendortag releasetag
Checking in binary files
Since CVS does some handy things automatically like keyword expansion (see pg 116 of CVS book) and line-ending conversions (for multiplatform support) you'll need to tell it to disable these two things when checking in binary files (so it won't munge them up) for obvious reasons.
cvs add -kb filename (disable keyword expansion and line-ending conversion)
cvs add -ko filename (just disable keyword expansion)
read lock failed - giving up - Part II
- Even if you have set the sgid bit to properly inherit the gid of the parent directory when creating new directories using cvs add, the actual file permissions will depend on the umask of the user that is adding the directory. If the umask is 0022 the directory will be created as 755 which is problematic because during a checkout, other users won't be able to write lock files even though they belong to the right group.
- There are at least two ways to address this issue. One is to set the LockDir variable in CVSROOT/config and the other is to set the CVSUMASK environment variable.
- The CVSUMASK is described in more detail at http://ximbiot.com/cvs/manual/cvs-1.11.21/cvs_2.html#SEC13.
- The LockDir variable is described at http://ximbiot.com/cvs/manual/cvs-1.11.21/cvs_18.html#SEC184.
- The CVSUMASK option seems more appropriate for what we want to do in hdbstat/client. Committers to that module should set their CVSUMASK.
read lock failed - giving up
- When another user creates a directory or file, the usual behavior is to inherit the default group of the user. This may not be desirable if the permissions are set in terms of another group (say, statgen) then other users may get a read lock failed if they are not a member of the default group of the first user.
- One proposed fix is to set the sgid bit (e.g. chmod g+s) of the CVS module directories so that newly created directories inherit the groupid of parent directories.
- See http://lists.gnu.org/archive/html/info-cvs/2001-06/msg00274.html.
- http://ximbiot.com/cvs/manual/cvs-1.11.21/cvs_2.html <-- read under file permissions for how to set up your repository and comments on setgid and CVSUMASK
Avoid spurious conflicts during merging
Why is cvs checkout/update so slow when dealing with large files?
I've observed when checking out mdac and power_atlas that grabbing the supporting XLS and SOFT files can take forever, certainly longer than could be reasonable expected based on the network speed.
This thread has some interesting comments that we should probably follow up on: