CVS Command Line Commands
From WoWIIIDev
Basic CVS Commands
This page will give a short intro to the basic cvs commands
Pserver/Login
You need to tell CVS the name of the server that you want to check stuff out from, the default CVS repository will be $CVSROOT, so if you dont use any others then you should probably export that as an env variable such as:
export CVSROOT=:pserver:USERNAME@cvs.worldsofwar.co.uk:/home/cvs/fh
after you have done this you need to issue a cvs login to enter your password.
Alternatively you can issue a -d to override the default cvs root like: cvs -d :pserver:USERNAME@cvs.worldsofwar.co.uk/home/cvs/fh checkout
Basic Commands
| Name | Command | Description |
|---|---|---|
| Checkout | cvs co $MODULE_NAME OR cvs checkout $MODULE_NAME | Checks out the head of the module, use -r to checkout a specific tag or head of a specific branch (ie cvs co -r flop_the_plop $MODULE_NAME) |
| Move to head/branch/tag | cd $MODULE_NAME cvs update | cvs update is mostly useful when giving arguments, on its own cvs update will take you to the latest working copy for that branch/tag (so if you checked out a tag which has not been branched then it wont do anything). The most useful arguments are -A or -r, -A means take me to the current head, -r means take me to the given branch/tag. Cvs update should always be used with -d which means download new directories (if new directories have been added then cvs update wont download these new directories without -d).
cvs update will also show you the files that it changes and have been changed by you, so you can use cvs update to see what changes you have not yet added or committed. |
| Add a file to CVS | cd wherever/the/file/is cvs add filename.file | WARNING!!!!!!! CVS is not clever enough on its own to work out the type of file your adding. If your adding a plain text document (HTML/Java/SQL/JavaScript.........) then cvs add filename.file is fine. If you adding a binary file (JAR/Image..........) you MUST tell cvs its a binary file, do this with:
cvs add -kb filename.file The -kb tells cvs the file is binary, failing to do this will mean you will get some upset messages from the developers using some chonkey old crap operating system. Linux/Unix can handle the omission of the -kb, but windows cant! There is actually a good reason for this (well its only good in some people eyes as this goes back to the DOS days and its to do with the representation of new lines) |
| Commit a file to CVS | cvs commit filename.file | In order to commit a file it must be in the repository, either added by you or already in there when you checked it out. When you issue a commit you need to provide a comment about the file, the preferred practice is:
cvs commit backend.file frontend.file Message: Changed the way the flags are presented so that they are no longer forced to be the same as the race name. (ie here I am committing two files at the same time giving them the same comment, in this case the two files are part of one logical change, this is good as it saves you typing, and when you see two files committed at exactly the same time, by the same person, with the same comment, you can kinda guess they are related). Cvs commit . THIS IS EVIL, this tells cvs that you have no idea what your doing, and that some poor git will probably have to go and unpick all your changes. Basically you should commit little and often, so if you make a small change, commit when your happy it compiles and works, this makes it a million times simpler to keep track of what you have changed, causes the minimum chance of conflicts (which can take ages to sort out) and makes problems simpler to fix later. You can also do cvs commit -m “here is a message” file1.file, its a bit plop but it works, if you want to change the editor that is loaded then you need to do: export EDITOR=vim (vim being my preferred editor) |
| Create a tag | cd $MODULE_NAME
cvs tag $TAG_NAME |
You need to have everything checked in for this to work (not necessary at the head). This will attach the given tag name to all the files at the current versions you have checked out. Tagging is good for things like testing, as it allows you the option of always checking out the same version of the files.
The format for tags should be: usernameYYYYMMDD_HHMM For example scott20090914_1016 Tags should be entered on matis explaining what their purpose is. |
| Create a branch | cvs tag -c -b $BRANCH_NAME | Branches are good for concurrent development, but should not be created unless they really are needed, for example two users working on the same file does not need a branch. The best explanation for using a branch would be user 1 needs to change file a to fix some bugs, but user 2 has already changed the head of file a for part of a total re-write.
Branch names should be in lower case underscore separated and as descriptive as possible, for example: tick_engine_redevelopment Remember creating a branch does not move you onto that branch, you need to do an update for that. |
| Diff a file | cvs diff filename.file | Shows the differences that exist between the version you checked out and the working version you have |
| Status of a file | cvs status filename.file | Shows you the current status of a file (ie locally modified, up to date, etc) |
| Log of changes | cvs log filename.file | Shows you a log of all the changes made to a single file, and all the tags with it and the branches |
