Found at: http://publish.ez.no/article/articleprint/17
|
Version Control management with CVS - Part 1
|
CVS is a Version Control System which helps multiple developers manage software projects. I'll not discuss whether or not CVS is the best choice over other free and commercial Version Control Systems, I'll instead show how CVS is used and give some small tips. This first part deals with setting up CVS locally, checking out a project and getting updates.
Setup
Before you start using CVS you'd better setup a couple of environment variables. All examples uses bash syntax.
First the CVS root needs to be set, this tells the CVS program were to look for projects unless another root is set explicitly. The CVSROOT variable consists of four items:
1. The protocol type, this can either be the use of pserver, remote shell execution (RSH and SSH) or locally.
2. The user name which has CVS access.
3. The server on which the repository resides.
4. The path on the server to the repository.
For instance using pserver, which is often used in local LANs, you could do
export CVSROOT=:pserver:user@server:/path/to/cvsroot |
where user is your user on the remote server, server is the remote server and the /path/to/cvsroot is the path on the remote server.
You can also have the repository on your local machine in which case you write
export CVSROOT=:local:/path/to/cvsroot |
where /path/to/cvsroot is the same as the one above but now locally. If you want to you can skip the :local: prefix since it is only needed on the MS-Windows platform where the path often contains a :.
The last and most used mode on the Internet is by using so called remote shell execution, this is done with either RSH (very insecure and not recommended) or with SSH. Before you use this you need to set another shell variable, namely CVS_RSH. To use SSH you would write
you would then change the CVSROOT to
export CVSROOT=user@server:/path/to/cvsroot |
where the user, server and /path/to/cvsroot is exactly the same as in the pserver example above.
One last thing you should do is to set the default editor for committing changes. If this variable is not set CVS will use vi for editing, so unless you're a vi fanatic you probably want to change it to something more sensible for you. Good editors for this kind of use are pico, nano or nedit. You can also use Emacs for this but I would recommend using the emacsclient, it saves a lot of loading time.
So to change it to use pico you simply perform this shell command:
If you want these variables to be set each time you log in you can add them to your ~/.bashrc or ~/.bash_profile file.
Logging in
If the repository you're working is using the pserver protol, you might want to login to it to avoid typing your password on every CVS action. However if you're very concerned with security you might want to skip this, the reason is that when you login the password is stored, although encrypted, on your local account in a file called .cvspass, but that's entirely up to you.
Logging in is done with the CVS command login. What we're going to do is to try to log in to a remote repository with an anonymous user, this gives us read-only access to the repository. To have something concrete to try it out on I'll use my own project on Sourceforge as example.
cvs -d:pserver:anonymous@cvs.RegExplorer.sourceforge.net:/cvsroot/RegExplorer login |
You will then be prompted for a password. This is normally were you write in your password for the remote user, but in this case we simply press Enter(or Return). We are now logged in to the remote repository and no longer need to pass a password for all CVS operations.
Time to move on to the real commands.
Checking out
If you already have a project that you wish to "check out" there a couple of simple steps to it:
What you first need to figure out is where the repository is located, if it's in the same place as the CVSROOT you set earlier you're set to go, if not you must supply a parameter to the CVS command.
The next thing you need to decide is which project you want to check out, this is either done with a path in the repository or with a CVS module name.
Checking out is done with the CVS command checkout
or the short version
where the module is either the name of the defined module on the CVS server or the relative path to the project.
To use another repository than the default you must specify this with the -d option, this is called a global option and is always put before the CVS command. So if we wanted to check out the RegExplorer project we would do
cvs -z3 -d:pserver:anonymous@cvs.RegExplorer.sourceforge.net:/cvsroot/RegExplorer co regexplorer |
You should now get a local copy of the CVS project. You might have noticed the use of the global -z3 option. This simply tells the CVS program to use the gzip compression when sending data over the network, this helps the transfer speed when using the Internet, the number 3 is the compression-level for the gzip program.
The local copy will present in the subdirectory regexplorer on your local machine, the module name is always used for creating a local subdirectory. You can now enter this directory, look around and make changes.
Any changes you make to this project will not have any impact on the repository version, there are two reasons for this.
The first reason is that you accessed the CVS server with an anonymous user which only gives you read-only access. To get write access you will need a user on the repository server and checkout the project with that user.
The second reason is that any changes by you on your local machine will not be incorporated to the remote server before you do a commit. How to do a commit is explained in a future part.
Updating
Updating, one of two widely used CVS commands, is vital to any cvs project. It makes sure your local copy is up to date with the remote repository.
First lets picture a scenario:
You successfully checked out the project and have used it successfully for a couple of days. You then get a message from your friend telling you that a new super cool feature has been committed to the project. And of course you're interested in getting it.
Well the solution is simple, what you need to do is to perform a CVS action called updating, this is done with the CVS command update. To do the update you first need to change the current directory to wherever you have the project locally, then you do a
or using the short form
there is no longer any need to specify the location of the repository this is because when you checked out the project the location was stored locally.
When you execute the command you will notice that it lists a couple of files with some letters in front of them. The letter in front gives you a clue on the status of the file. For instance
U means the file was brought up to date.
P means the file has been patched with the repository version.
A the file was added by you but not committed yet.
R the file was removed by you but not committed yet.
M the file has been modified by you but not committed yet.
C the file has been committed by you locally and in the repository so a conflict has occurred, more information on conflicts follows in the next part.
? the file is not part of the CVS project.
One thing to notice when you update is that you only get the changes in the files you already have locally. Any new files or directories will not be downloaded. To make sure you get those too you have to add an update specific option -d.
The reason for not updating all files by default is that you sometimes don't want all files in a project and has explicitly checked out only a small portion of them, it can then be very annoying if the number of files just keeps increasing on each update.
Another option, which can be useful, is to stop the CVS program from recursing trough subdirectories. Sometimes you just want to perform an action in the local directory. To perform a non-recursive update you do
which performs the update but only in the current directory.
One other handy trick you can do with the update command is to get a simple status report on the repository. Sometimes you're just curious if the CVS repository has changed in any way but don't want to do an actual update to find out. To do this you have to specify the global -n option. This option tells the CVS program not to perform any changes to the local files. We can then do
we then get the same list of files as we do with a normal update but no files are changed. You can then easily pick out which files need patching, which ones are new and which ones are removed.
Conclusion
You should now have to knowledge to login, check out and update projects from a CVS repository. These are the only things you need to know if you're only interested in using other peoples projects. For instance it allows you to download bleeding edge versions of your favorite programs, no need to wait for the next binary release. You can also help a developer find bug reports in the very latest version, this is much appreciated by most, if not all, developers.
Look out for the next part where we'll go into the details of committing changes, creating patches and learn the secrets of version numbers. 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.