CVS Commands

CVS CommandsCVS Commands

數位芝麻網路公司數位芝麻網路公司蔡志展蔡志展

<<[email protected]>[email protected]>

2001/8/182001/8/18

CVS Commands add

Add a new file/directory to the repository

admin Administration front end for rcs

annotate Show last revision where each line was modified

checkout Checkout sources for editing

commit Check files into the repository

diff Show differences between revisions

CVS Commands

edit Get ready to edit a watched file

editors See who is editing a watched file

export Export sources from CVS, similar to checkout

history Show repository access history

import Import sources into CVS, using vendor branches

init Create a CVS repository if it doesn't exist

CVS Commands

log Print out history information for files

login Prompt for password for authenticating server.

logout Removes entry in .cvspass for remote repository.

rdiff Create 'patch' format diffs between releases

release Indicate that a Module is no longer in use

remove Remove an entry from the repository

CVS Commands rtag

Add a symbolic tag to a module

status Display status information on checked out files

tag Add a symbolic tag to checked out version of files

unedit Undo an edit command

update Bring work tree in sync with repository

watch Set watches

watchers See who is watching a file

Starting a project with CVS

When you begin using CVS, you will probably already have several projects that can be put under CVS control. In these cases the easiest way is to use the import command. An example is probably the easiest way to explain how to use it. If the files you want to install in CVS reside in `myproj', and you want them to appear in the repository as `$CVSROOT/myproj', you can do this:


Build the myproj directory tree.

$ cd myproj$ cvs import -m "Imported sources" myproj d11e start


Congratulations! If you ran that command (or something similar), you've finally done something that affects the repository.

Reading over the output of the import command, you'll notice that CVS precedes each filename with a single letter - in this case, "N" for "new file". The use of a single letter on the left to indicate the status of a file is a general pattern in CVS command output. We'll see it later in checkout and update as well.

Reminder

You might think that, having just imported the project, you can start working in the tree immediately. This is not the case, however. The current directory tree is still not a CVS working copy. It was the source for the import command, true, but it wasn't magically changed into a CVS working copy merely by virtue of having been imported. To get a working copy, you need to check one out from the repository.

Checking Out A Working Copy

The command to check out a project is exactly what you think it is:

$ cvs checkout myproj

Making A ChangeFinding Out What You (And

Others) Did “cvs update” or “cvs up”

cvs update

Usage: cvs update [-APdflRp] [-k kopt] [-r rev|-D date] [-j rev] [-I ign] [-W spec] [files...] -A Reset any sticky tags/date/kopts. -P Prune empty directories. -d Build directories, like checkout does. -f Force a head revision match if tag/date not found. -l Local directory only, no recursion. -R Process directories recursively. -p Send updates to standard output (avoids stickiness). -k kopt Use RCS kopt -k option on checkout. -r rev Update using specified revision/tag (is sticky). -D date Set date to update from (is sticky). -j rev Merge in changes made between current revision and rev. -I ign More files to ignore (! to reset). -W spec Wrappers specification line.

Status of file U file The file was brought up to date with respect to the repository. This is done for any file that exists in the repository but not in your source, and for files that you haven't changed but are not the most recent versions available in the repository.

A file The file has been added to your private copy of the sources, and will be added to the source repository when you run `cvs commit' on the file. This is a reminder to you that the file needs to be committed.

Status of file R file The file has been removed from your private copy of the sources, and will be removed from the source repository when you run `cvs commit' on the file. This is a reminder to you that the file needs to be committed.

M file The file is modified in your working directory. `M' can indicate one of two states for a file you're working on: either there were no modifications to the same file in the repository, so that your file remains as you last saw it; or there were modifications in the repository as well as in your copy, but they were merged suc- cessfully, without conflict, in your working directory.

Status of file C file A conflict was detected while trying to merge your changes to file with changes from the source repository. file (the copy in your work<AD> ing directory) is now the result of merging the two versions; an unmodified copy of your file is also in your working directory, with the name `.#file.version', where version is the revision that your modified file started from. (Note that some systems automatically purge files that begin with `.#' if they have not been accessed for a few days. If you intend to keep a copy of your original file, it is a very good idea to rename it.)

Status of file

? file file is in your working directory, but does not correspond to anything in the source repository, and is not in the list of files for cvs to ignore (see the description of the -I option).

Committing

The commit command sends modifications to the repository. If you don't name any files, a commit will send all changes to the repository; otherwise, you can pass the names of one or more files to be committed (other files would be ignored, in that case).

Usage: cvs commit [-nRlf] [-m msg | -F logfile] [-r rev] files... -n Do not run the module program (if any). -R Process directories recursively. -l Local directory only (not recursive). -f Force the file to be committed; disables recursion. -F file Read the log message from file. -m msg Log message. -r rev Commit to this branch or trunk revision.

Detecting And Resolving Conflicts

Detecting a conflict is easy enough. When you run update, CVS tells you, in no uncertain terms, that there's a conflict.

Finding Out Who Did What (Browsing Log Messages)

Usage: cvs log [-lRhtNb] [-r[revisions]] [-d dates] [-s states] [-w[logins]] [files...] -l Local directory only, no recursion. -R Only print name of RCS file. -h Only print header. -t Only print header and descriptive text. -N Do not list tags. -b Only list revisions on the default branch. -r[revisions] Specify revision(s)s to list. -d dates Specify dates (D1<D2 for range, D for latest before). -s states Only list revisions with specified states. -w[logins] Only list revisions checked in by specified logins.

Examining And Reverting Changes

Usage: cvs diff [-lNR] [rcsdiff-options] [[-r rev1 | -D date1] [-r rev2 | -D date2]] [files...] -l Local directory only, not recursive -R Process directories recursively. -D d1 Diff revision for date against working file. -D d2 Diff rev1/date1 against date2. -N include diffs for added and removed files. -r rev1 Diff revision for rev1 against working file. -r rev2 Diff rev1/date1 against rev2. --ifdef=arg Output diffs in ifdef format.

Adding File

Usage: cvs add [-k rcs-kflag] [-m message] files... -k Use "rcs-kflag" to add the file with the specified

kflag. -m Use "message" for the creation log.

Adding Files

Adding a file is a two-step process: First you run the add command on it, then commit.

Adding Directories

Unlike adding a file, adding a new directory is done in one step

CVS And Binary Files All the files we've been working with until now have been plain

text files. CVS has some special tricks for text files. For example, when it's working between a Unix repository and a Windows or Macintosh working copy, it converts file line endings appropriately for each platform. For example, Unix convention is to use a linefeed (LF) only, whereas Windows expects a carriage return/linefeed (CRLF) sequence at the end of each line. Thus, the files in a working copy on a Windows machine will have CRLF endings, but a working copy of the same project on a Unix machine will have LF endings (the repository itself is always stored in LF format).

CVS And Binary Files

Another trick is that CVS detects special strings, known as RCS keyword strings, in text files and replaces them with revision information and other useful things.

cvs add –kb file

Removing Files

“cvs remove” or “cvs rm”

Usage: cvs remove [-flR] [files...] -f Delete the file before removing it. -l Process this directory only (not recursive). -R Process directories recursively.

Removing Directories

CVS doesn't really keep directories under version control. Instead, as a kind of cheap substitute, it offers certain odd behaviors that in most cases do the "right thing". One of these odd behaviors is that empty directories can be treated specially.

Renaming Files And Directories

Remove the old files, and add the new ones. Renaming directories is not done very differently:

create the new directory, cvs add it, move all the files from the old directory to the new one, cvs remove them from the old directory, cvs add them in the new one, cvs commit so everything takes effect, and then do cvs update -P to make the now-empty directory disappear from the working copy. That is to say:

Getting Snapshots (Dates And Tagging)

Let's return to the example of the program that's in a broken state when a bug report comes in. The developer suddenly needs access to the entire project as it was at the time of the last release, even though many files may have been changed since then, and each file's revision number differs from the others. It would be far too time-consuming to look over the log messages, figure out what each file's individual revision number was at the time of release, and then run update (specifying a revision number with -r) on each one of them. In medium- to large-sized projects (tens to hundreds of files), such a process would be too unwieldy to attempt.

Acceptable Date Formats

$ cvs update -D "19 Apr 1999" $ cvs update -D "19 Apr 1999 20:05" $ cvs update -D "19/04/1999" $ cvs update -D "3 days ago“$ cvs update -D "5 years ago“$ cvs update -D "19 Apr 1999 23:59:59 GMT“$ cvs update -D "19 Apr"

Marking A Moment In Time (Tags)

Retrieving by date is useful when the mere passage of time is your main concern. But more often what you really want to do is retrieve the project as it was at the time of a specific event - perhaps a public release, a known stable point in the software's development, or the addition or removal of some major feature.

Trying to remember the date when that event took place or deducing the date from log messages would be a tedious process. Presumably, the event, because it was important, was marked as such in the formal revision history. The method CVS offers for making such marks is known as tagging.

Tags differ from commits in that they don't record any particular textual change to files, but rather a change in the developers' attitude about the files. A tag gives a label to the collection of revisions represented by one developer's working copy (usually, that working copy is completely up to date so the tag name is attached to the "latest and greatest" revisions in the repository).

Branching Basics

Creating A Tag Or Branch Without A Working Copy

Usage: cvs rtag [-aflRnF] [-b] [-d] [-r rev|-D date] tag modules... -a Clear tag from removed files that would not otherwise be tagged. -f Force a head revision match if tag/date not found. -l Local directory only, not recursive -R Process directories recursively. -n No execution of 'tag program' -d Delete the given Tag. -b Make the tag a "branch" tag, allowing concurrent development. -r rev Existing revision/tag. -D Existing date. -F Move tag if it already exists

Creating A Tag Or Branch Without A Working Copy

There is such a way: the rtag command (for "repository tag"). It's very similar to tag; a couple of examples will explain its usage. Let's go back to the moment when the first bug report came in and we needed to create a branch rooted at the last public release.

Annotations - A Detailed View Of Project Activity

If the history command gives an overview of project activity, the annotate command is a way of attaching a zoom lens to the view.

The Fast Method Of Reverting

The fast, fancy way of reverting is to use the -j (for "join") flag to the update command. This flag is like -r in that it takes a revision number, and you can use up to two -j's at once. CVS calculates the difference between the two named revisions and applies that difference as a patch to the file in question (so the order in which you give the revisions is important).

Tips

.cvsignore

Documents

CVS Commands