CVS Commands 數位芝麻網路公司蔡志展 2001/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:

Starting a project with CVS Build the myproj directory tree. $ cd myproj $ cvs import -m "Imported sources" myproj d11e start

Starting a project with CVS • 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 Change Finding 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 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 :05" $ cvs update -D "19/04/1999" $ cvs update -D "3 days ago“ $ cvs update -D "5 years ago“ $ cvs update -D "19 Apr :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