Server-side CVS Administration

This section only describes my recommended OS-level Server-side Administration strategy. It does not describe user-level CVS Administration commands such as creating branches. Those items are covered elsewhere in this document. The work covered herein must be performed on the host which houses the repository you want to work with.

Whenever you edit files under the repository root, always use RCS (i.e., co and ci). See the man pages for co and ci at http://linuxcommand.org/man_pages/co1.html and http://linuxcommand.org/man_pages/ci1.html. Remember that RCS switches take trailing space in a manner exactly opposite to that of CVS. Whereas CVS takes a space after switches, like

         cvs... commit -m 'blah blah...
     

         ci... -m'blah blah...
     

Security

Due to time constraints, I am describing only our normal, typical setup.

Any UNIX user in the OS group cvs may read the resources in any CVS module.

For a UNIX user to be able to update (add, remove, modify) resources in a CVS module, some (any) OS group to which they belong must be listed in the file scripts/modulegroup.list under the CVS repository root.

For a UNIX user to be able to perform OS-level CVS Administration (i.e., add new modules, grant and revoke privileges), they must be in the OS group "cvsadm". To perform this work, the user runs the command

         sudo.alt su - cvs
     

How to create a new CVS Module

1. Create the directory of the module name under the CVS Respository root, and set the ownerships and permissions to cvs/cvs 02775.

                 cd /the/repos
                 mkdir new-ejb new-web
                 chown cvs:cvs new-ejb new-web
                 chmod 0775 new-ejb new-web
                 chmod g+s new-ejb new-web
             

   (Our version of Solaris can't handle chmod 02775).
2. Add an OS group if necessary (in the next step you will grant write access to the module with OS groups).
3. Check out (with co) and edit the file scripts/modulegroup.list according to the comments in that file (see the description about modulegroup.list above). Remember to check it back in with ci.
4. Check out (with co) and edit the file CVSROOT/modules. This step has no effect on WSAD whatsoever, since WSAD doesn't use module aliases. This sets up aliases which make it very easy to manage tags from the CVS command line.
   1. If other development teams work with binaries that you create (like a .jar or an -ejb.jar file), then create an alias for each of them, and add this alias to all existing -all aliases which depend upon it.

                         newAccounting.jar -a new-ejb/bin/accounting.jar
                         newAdding.jar -a new-ejb/bin/newAdding.jar
                         # Adding newAccounting.jar onto dependencies for the EMT project:
                         emt-all -a emt-ali storeshared-ali coreEJB.jar newAccounting.jar
                     

      The names for aliases for files should contain a dot so users can easily see that it is an alias for a file and not a module. The name must make it obvious what CVS module the file comes from, in order to avoid confusion and future name collisions. The value of these aliases is a relative path from the repository root directory.
   2. If this is a new application, define a new alias for this module(s), otherwise, add the new module(s) to the alias which should contain this module(s).

                         # Adding alias for application "new".
                         new-ali -a new-ejb new-web
                     

      The name should end with -ali so users can easily see that it is a simple (non-nested) alias for module(s). Note that we list only CVS modules, not file aliases nor other aliases, in -ali aliases.
   3. If this is a new application, define a new -all alias, and also add our new -ali alias to all existing -all aliases which depend upon it. For example, if we were adding the storeshared modules, we would have added storeshared-ali in the previous step, and we would now add storeshared-ali to the store-all, emt-all and ast-all aliases. For our current example, we are adding a new application that depends on storeshared-ali and the core ejb jar file (but nothing else depends upon our new stuff).

                         new-all -a new-ali storeshared-ali coreEJB.jar
                     

      The name should end with -all so users can easily see that it is a nesting alias for all the resources needed for our application.
   4. Check the definition for all-all. If it does not somehow include the items you added, then add them. (E.g., if you defined a new *-ali, you will probably need to add that *-ali to all-all). This is important so that users can build your code using a tag even if your application-specific aliases get messed up.
   5. Remember to check the modules file back in with ci.