WorkingWithCVS
This page is obsolete; please see Working with Git for current version control procedure.
CVS Basics
This node discusses the basics of using CVS. Also see Checking out CVS modules on sourceforge.net
For complete on information CVS, including the basics, see:
For information on more advanced usage, see:
- WorkingWithCVSBranches - making branches and merging between them
Concepts
The Repository
CVS stores source code in a shared repository (in our case on Sourceforge's server). The repository contains all past and present versions of the code, and is shared by everyone.
Your Working Copy
To work with the source code, CVS requires you to check out a working copy. This copy is private, so you can make and test any changes you like without disturbing anyone else.
If you have write access to the repository, when you are finished making your changes, you may commit your changes to the shared repository, making them available to everyone.
Alternately, you may generate a file containing the changes you made (a diff), and send it to a developer with write access to be incorporated.
You can check out as many working copies as you want; they take up only your own disk space, and they are completely independent of each other.
If you no longer need a working copy, you may simply delete it.
Getting Started
Setting Up
Default Settings
Create a .cvsrc file in your home directory with the following contents:
cvs -z3 -q diff -uNp update -Pd remove -f
Anonymous Access
Most developers will initially only have access to a read-only copy of the repository. You will need to run the following command once:
cvs -z3 -d :pserver:anonymous@cvs.sourceforge.net:/cvsroot/inkscape login
And then simply press enter when asked for a password (the password is blank).
Note that this read-only copy is normally ~24 hours behind the newest changes.
Write Access
Developers who have been given write access (access to the master repository) will need to have ssh installed, and set their CVS_RSH environment variable to ssh.
To avoid being prompted for your Sourceforge password every time you run a CVS command on the master repository, you will probably want to upload an SSH key.
If you've been doing work in a codebase checked out as anonymous, you can convert it to your developer account with a little work. Essentially, you need to recursively convert all of the CVS/Root files in the tree from the anonymous user to your username. Alternatively, you can just create a diff and then patch it over.
How Do I Check Out a Working Copy?
To check out a copy of Inkscape from the developer CVS, you may use the following command:
cvs -z3 -drepository checkout inkscape
Here are what the options mean:
-z3 is a general CVS option, and requests that communication with the server be compressed to save bandwidth. Recommended especially if you are on dialup.
-d specifies the repository to check out from.
"checkout" ("co" means the same thing) specifies the action to take (check out a working copy).
"inkscape" is the name of the module (group of files and directories) that make up our project.
Which Repository Do I Use?
Most users will use the anonymous repository (:pserver:anonymous@cvs.sourceforge.net:/cvsroot/inkscape), as shown above.
If you are a developer who has been given CVS write access, the repository will be :ext:username@cvs.sourceforge.net:/cvsroot/inkscape, where username is your sourceforge username.
Now What?
You should have a complete working copy in the inkscape directory. You can cd to it and try compiling.
- Note: If it is a fresh checkout, you will need to run the ./autogen.sh shell script at the top level to create files needed to compile
You should not need to specify the repository with -d in any CVS commands for this working copy. CVS remembers which repository a working copy came from.
Note that a CVS command only applies to the current directory and (possibly) any subdirectories. Normally (particularly for updates, diffs, and checkins), you will want to run the command from the top level of the project.
Bringing Your Working Copy Up-To-Date
Your working copy will not automatically include changes others have made to the repository since you checked it out.
To update your working copy, use this command:
cvs -z3 update -Pd
-P specifies to remove any directories that become empty as a result of the update
-d creates any new directories introduced by the update
Dealing with Conflicts
If you've made changes to your working copy, what happens if you update after someone has commited changes to the same files?
Normally, CVS can work this out on its own. Sometimes you have to help it along, though. If CVS says there were conflicts, look for which files have a C next to them in its progress output. Some of those may have unresolved conflicts. You can also search for '=======' in the files themselves to find any unresolved conflicts.
<<<<<<< filename The changes in your version will be here ======= The changes the other person will be here >>>>>>> some version here
Sometimes you will keep one set of changes and discard the other, and sometimes you will combine the two. It will require a judgement call on your part either way. Talk to the person who made the other set of changes or ask on the mailing list if it's unclear what's going on. Remember that CVS is no substitute for communication.
Also, always make sure to build and test after an update to make sure that the combined changes work as intended.
Generating a Diff
(Always update before generating a diff!)
From the top-level directory, run the command:
cvs -z3 diff -u3 > filename
-u3 specifies which format to use (a unified diff with three lines of context). This is the recommended diff format.
This will create a file describing the changes you have made, though if you have created new files as part of your changes, you will need to include those separately too when emailing them to the list or another developer for inclusion.
Automatic Commit Diff
To always generate a diff when you commit to CVS, set the environment variable "CVSEDITOR" to the following script:
#!/bin/bash # get rid of redhat 9 locale ugliness unset LC_CTYPE # Turn on ro access (to stop multiple locks) for local roots grep @ CVS/Root >/dev/null 2>&1 || export CVSREADONLYFS=1 # Tell the user what's going on echo Building diff... cvs diff -up 2>/dev/null | perl -ne 'print "CVS: $_" unless /^\?/' >> "$1" exec ${EDITOR:-vi} "$1"
If the above script is named "~/bin/cvsdiffvi", then assuming you run the bash shell, you can add the following your .bashrc file:
export CVSEDITOR=~/bin/cvsdiffvi
Now, every time you commit, the entire diff will be visible to you as you write your commit comments.
Patching a Diff
A diff file can be applied to the codebase using the 'patch' command.
If the diff was made as inkscape/src/thingy.cpp and you're in the "inkscape" directory, you'll want to use the command:
patch -p1 < thingy.diff
Depending on how many path elements are part of the diff, you'll need to strip them with -p1, -p2, etc.
Committing your Changes
(Always update before committing!)
If you have write access to the repository, you can commit your changes like this:
Before you commit, please make sure that you describe the changes you have made in the ChangeLog file at the top-level directory.
cvs -z3 commit -m "Your description of your changes goes here"
Tip: even if you are committing directly, you still might want to generate a diff. It's a good reference to look at when you're filling out the ChangeLog, since it will remind you of all the changes you've made.
Adding Files to the Repository
To add new files as part of your commit, you will need to run:
cvs -z3 add files and directories to add go here
Before you commit. This also goes for new directories.
Except for directories, the actual addition or removal will not take effect until you commit.
Removing Files from the Repository
To remove files from the repository (they aren't actually removed, just marked as inactive), you will need to run:
cvs -z3 remove files that were removed go here
The files will have to have been deleted from your working copy before CVS will let you do this.
The actual removal will not take effect until you commit.