CVS Notes

Make sure that this is in ~/.bashrc.

For remote CVS use, put these in the .bashrc:

Source your .bashrc if echo $CVSROOT produces nothing.

Go to the repository.

Set it up while in the repository dir. Only do this once for a new place for CVS to store stuff.

Go back to the directory you were interested in archiving.

Optional Check out the config CVS file to have a look This can go anywhere and you can make modifications to the config files that are stored by CVS. Do an update to make changes take effect.

Go to where the source code is. Here imagine that the source is being kept in a series of directories that get copied every week (a crude RCS).

Set up project (i.e. "module"). This must be done from the project’s directory. All files in the current directory will recursively be tracked. The module name is "GeoGad". Here "XedTech" is a "vendor tag". Here "START" is a "initial tag".

After creating a module, the files involved have to be checked out before they can be properly used by CVS. This makes a new directory called GeoGad so you might have to go up a directory if you want to to have the CVS version repopulate the GeoGad directory you’re already in.

To set up a module in CVS before any source code is written, use any empty directory.

Go to where you want to work on this project.

Get a CVS ready directory (called "nova") to work in.

Change to this directory, create files and then "cvs add" them.

Imagine a project that’s a total mess, some files in the directory are backups done by hand and therefore shouldn’t be part of a CVS import. Start by moving the directory so that you can use this name for a new and improved CVS version:

Make a new empty version of the directory:

Go to that directory:

Copy in the files that need to be there; leave the bogus stuff.

Make a CVS project out of it:

Make the source directory a working CVS directory:

Optionally delete the original directory:

To add files to the CVS module, set it up for addition and when a commit is done the file will be tracked too.

Deleting files from CVS’s control is similar to add.

Before doing anything that might have been touched by other developers (or you from somewhere else), it’s important to make sure you are working with the latest versions. The -d will create any new files that don’t exist on your current version. $ cvs update -d

Put this in the .bashrc (assumes $XED is defined as the IP#)

Check out like this:

If you start a project with a certain name, but later think of a better one, then you need to change the CVS name. There are other ways to do this, but this is pretty safe. Go to the CVSROOT directory where this project lives. Then make an exact copy to the new name:

Go back to your working directory and:

Start using it. If everything is ok, then you can delete the old working directories and the old version in CVSROOT:

Note that there may be some references to the old project in the history file of $CVSROOT/CVSROOT.

The following keywords can be embedded in source code files and will get expanded into something more meaningful. The format is

Replace "Keyword" with one of these:

Personally I use $Date:$ and $Revsion:$ which seem the simplest and most useful.

$ sudo mkdir /aleph1/svn $ sudo chmod 770 /aleph1/svn $ sudo svnadmin create /aleph1/svn $ sudo chgrp -R aleph1 /aleph1/svn $ sudo chmod -R g+rw /aleph1/svn/db /aleph1/svn/locks

Note- I did all of this already so normal users can jump right to the next step.

SVN keeps track of stuff as if it was in a special file system. You can customize the contents of this file system. For example, you might want to start with a sub directory for all your projects:

And then you can start an empty project if you’re about to embark on one with no pre-existing files:

Notice that you’ve created a directory in the virtual svn file system and then checked it out to a place in the real file system. Doing it in this way is important because now the directory in the real file system is trackable by Subversion as indicated by the existence of the .svn housekeeping directory.

If you already have a bunch of files under development and want to begin tracking them all with svn, use the "svn import" command. This will take an existing directory tree and install it into Subversion management:

This does not make the existing directory understand Subversion, however. This just allows subversion to get some files. To have Subversion be able to care for files you can actually work with, you have to check the import back out.

If you’ve started with the intent to use Subversion from before your project has any files, you need to add the files to the repository. Do this by:

The "svn add" tells Subversion that you want this file to be tracked. The "svn ci" commits your addition. Before doing the commit, someone else doing a checkout wouldn’t see this.

Change some things. For example:

Now that some files have been edited, it’s best to see if there are any conflicts, i.e. did some other user make the same changes while you did?

From the remote machine (for example, princeton):

(lj is a host alias for lajolla, see /etc/hosts)

Hopefully you’ve been in the good habit of describing your check ins with a little descriptive statement using "-m". That wouldn’t be very useful if you couldn’t do anything with that. Here’s how to review it: $ svn log chnotify.py