Found at: http://publish.ez.no/article/articleprint/59
|
Version Control management with CVS - Part 3
|
CVS is a Version Control System which helps multiple developers manage software projects. In this third part I'll show the details of CVS repository management, that is creating a new CVS repository, importing sources and handling CVS modules. Part 1, Part 2.
Creating a repository
Before you start creating a repository you need to figure out where you want to have it. Make sure you are located on the machine with the repository and enter
cvs -d /home/cvsroot init
|
Exchange /home/cvsroot with the path to your repository.
You should then find a default setup for your CVS repository in your selected directory. If you look inside you'll find a directory called CVSROOT, this directory contains all your administrative files.
If you want to perform back routines on your CVS then simply backup all files found inside your selected directory. I suggest you read the postscript or PDF manual of CVS to get more information on CVS backup, there are a couple of issues which you need to know about.
If you're unhappy with the placement of your repository you can simple move the directory anywhere you want as there are no absolute paths in the configuration files.
Importing a project
Once you've created a repository you probably want to import your existing projects into it or perhaps create new ones. The procedure is the same except that importing an existing project involves more files.
All following examples assumes that the CVSROOT environment variable is properly setup.
The first thing you need to do is place yourself, not your physical being ofcourse, in the directory where your project resides (or create a new directory). Now you need to make sure that only the files that should be in CVS are here. Temporary files, backup files and other automatically generated files are generally not what you want in CVS, if they are present either delete them or move them outside this directory.
The next thing is to decide where you want the project in the repository. It's common to categorize projects by either vendor, project type or programming language (or all if applicable). Examples are:
projects/cplusplus/bogo-search
mycompany/pig-latin
music/apollo
|
So to import our very own music player into the repository we do
cvs import music/apollo apollo-team initial
|
The two parameters after the music/apollo are the vendor and release tag. The vendor tag is usually your company name, your group name or yourself. The release tag is the initial tag name for your project and is usually something like initial, start or the version number of your imported project. Also remember to write a proper message when asked for it.
Once this is done you can checkout the project in another directory by entering
You can then enter music/apollo to find your project. Now is the time to check if all files has been imported in CVS, if not move them to your local CVS repository and add them. It's usually a good idea to make a backup of your old non-CVS version of your project.
Managing modules
One thing you might have notice with the imported project was that when you checked it out you got a directory structure like music/apollo. From my perspective this is unnecessary since we need to go inside the music directory before getting to our project. To remedy this we can use CVS modules. They are basically named aliases for one of your CVS directories.
To add a new module we need to get access to one of the CVS administration files, namely the modules file. This is done by invoking
You should now have a directory called CVSROOT, look inside it and should find the file modules. Now edit it with your favorite editor, go to the bottom of it and add
Now commit your changes (update in case others have change it), remove the CVSROOT directory and try and checkout our newly named project and do
Voila, our project now resides directly in the apollo directory ready for development.
The modules file has other interesting features such as automatic include of sub-projects, but I'll leave that to another part.
Conclusion
You should now have the knowledge to start a new project or manage an existing one with the use of CVS. Combined with the knowledge learned in part 1 and 2 you're ready to do some serious project development.
The next part in this series will go into the dangerous world of branching, something which most medium and large projects needs to do one time or another. For those of you who simply cannot wait I recommend you either check out the man pages for CVS, read it's PostScript version (usually located in /usr/doc/), the online manual or the PDF document
Any comments on how to improve this article or future parts are very welcome.