|Documentation :||Hardware | Software | Tutorials||Wardrobe :||Jackets | Applications|
|Papers :||Notes | Proposals | Research||Administration :||Stock | Minutes | Progress|
CVSROOT=:ext:wearable@curare:/home/projects/wearable/cvsroot-MarkII CVS_RSH=sshNOTE: If you place these in your .bashrc file then don't forget to add these lines to make them visible to shells:
export CVSROOT export CVS_RSHASIDE: Until we set up a CVS server to properly oversee our repository, we will be forced to use the CVSROOT string as given above. The best (and intended) way to run a CVS system is to have all members of the development group commit files with their own user ID (i.e. CVSROOT=:ext:<user_id>@machine:/path/to/repository). This is what makes tracking changes to their changers possible. However, since we are not currently running a CVS server we are faced with repository file ownership problems. More specifically, every time someone makes a change to a file and commits it, the versioned file in the repository becomes owned by that person. And since our repository is becoming very large (esp. this website!) developers will start running into quota issues. The quickest solution we could think of was to force everyone to commit files as the group/user wearable.
cvs checkout .This will fetch all of the modules in the repository. (you can also replace the '.' with the name of a specific module that you want to retreive.)
cvs update .This will update your working directory with the latest versions of the files in the repository.
cvs add <filename>If you remove any files from a module then as well as removing them from your filespace use:
cvs remove <filename>
cvs commit <filename>
Each time you execute a commit, you will be asked to enter a comment about your changes (vi opens as the default comment editor). Please make your comments concise and descriptive. Not doing so makes tracking modifications extremely difficult!
NOTE: the third argument of each of the above examples is the name of the module, file, or directory that the command is to operate on. Not specifiying this argument invokes the command with the current directory as the default.
The normal development process is to make any changes you want on your local copy of the CVS tree, and to debug them by transferring (using scp) files to the NFS'd directory on Waihona (/home/wearable/Exported is mounted as /home on the Bitsy). Once you are happy with your changes, you can commit them back into the repository.