File: meta-cvs.html

package info (click to toggle)
mcvs 1.0.13-8
links: PTS
area: main
in suites: sarge
size: 668 kB
ctags: 648
sloc: lisp: 5,091; ansic: 223; sh: 190; makefile: 58
file content (689 lines) | stat: -rw-r--r-- 32,415 bytes
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
            "http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD><TITLE>Version Control with Meta-CVS 1.0-13</TITLE>

<META http-equiv="Content-Type" content="text/html; charset=ANSI_X3.4-1968">
<META name="GENERATOR" content="hevea 1.07">
</HEAD>
<BODY >
<!--HEVEA command line is: /usr/bin/hevea meta-cvs.latex -->
<!--HTMLHEAD-->
<!--ENDHTML-->
<!--PREFIX <ARG ></ARG>-->
<!--CUT DEF section 1 -->


<H1 ALIGN=center>Version Control with Meta-CVS 1.0-13</H1>

<H3 ALIGN=center>Kaz Kylheku</H3>

<H3 ALIGN=center>2003-12-31</H3><!--TOC section Table of Contents-->

<H2>Table of Contents</H2><!--SEC END -->

<UL><LI>
<A HREF="#htoc1">1&nbsp;&nbsp;Introduction</A>
<LI><A HREF="#htoc2">2&nbsp;&nbsp;Tutorial</A>
<UL><LI>
<A HREF="#htoc3">2.1&nbsp;&nbsp;Creating a Module</A>
<LI><A HREF="#htoc4">2.2&nbsp;&nbsp;Checking out a Module</A>
<LI><A HREF="#htoc5">2.3&nbsp;&nbsp;Anatomy of a Sandbox</A>
<LI><A HREF="#htoc6">2.4&nbsp;&nbsp;Making Changes</A>
<LI><A HREF="#htoc7">2.5&nbsp;&nbsp;Adding Files</A>
<LI><A HREF="#htoc8">2.6&nbsp;&nbsp;Reviewing Changes</A>
<LI><A HREF="#htoc9">2.7&nbsp;&nbsp;Error Recovery</A>
</UL>
<LI><A HREF="#htoc10">A&nbsp;&nbsp;Glossary</A>
</UL>

<!--TOC section Introduction-->

<H2><A NAME="htoc1">1</A>&nbsp;&nbsp;Introduction</H2><!--SEC END -->

Greetings, reader! You are about to become a user of version control software
called Meta-CVS. The primary function of version control software is to store
multiple versions of a group of documents, such as the source files of a
computer program. As programmers make changes to the program, they generate
new versions of source files, which are retained in the version control system.
They may also add files, delete files, rename files, reshape the directory
structure of the project; the history of these changes is also retained,
just are the changes to the contents of the files themselves.<BR>
<BR>
In addition, to be useful, a version control system must not only store file
versions but it must be able to identify groups of related versions, so that an
old version of the entire project can be retrieved as a unit. For example,
when the programmers decide to release the program, they must be able to assign
a symbolic name to the release, and that name must be associated with a
particular version of every file. This will allow the release to be later
retrieved using its symbolic name as a retrieval key.<BR>
<BR>
Secondly, a version control system must allow developers to make changes in
parallel to the same line (or <I>stream</I>) of development, and merge their
changes.
<A NAME="@default0"></A>
It must identify conflicting changes so that they can be resolved. In must also
allow for multiple parallel lines of development---independent version
histories known as branches. Branches are useful for stabilizing software prior
to the current release, while allowing new development to happen on the
next release. They are useful for going back to an old release and fixing
errors. They are also useful for isolating risky, experimental work. When such
work involves many changes or more than one developer, it can take place on its
own branch. A good version control system makes it easy to create branches, and
to merge new changes from the branch back to the original stream.<BR>
<BR>
Meta-CVS is not a fully self-contained version control system. It uses another
version control system called CVS to store documents, and also to store
additional information about documents which allows it to provide useful
behaviors that do not exist in CVS. Effectively, Meta-CVS acts as an agent
between you and CVS, which is easier to use and more capable than CVS.<BR>
<BR>
I wrote Meta-CVS because I was frustrated by the inability of CVS to treat the
directory structures of my projects as a versioned entity. At the same time, I
did not want to rewrite everything that already works well in CVS, such as
client-server operation, maintaining file version histories, and branching,
merging and conflict identification. Instead, I decided to write a software
layer which uses CVS as a foundation. That software layer would not only do
completely new things, like directory structure versioning, but also to
automate certain tedious tasks which are normally performed with great
difficulty by the users of CVS.<BR>
<BR>
Meta-CVS does not, and is not intended to, entirely shield you from knowing
anything about CVS. Firstly, Meta-CVS requires the CVS software and a CVS
repository. Users who want to use Meta-CVS have to know how to obtain and
install CVS and create a repository. Moreover, from time to time it is useful
or necessary to bypass Meta-CVS and invoke a CVS operation directly. This
guide does not teach CVS; you are strongly encouraged to read <I>Version
Management with CVS</I> by Per Cederqvist et al. <A NAME="@default1"></A><BR>
<BR>
If you do not have a CVS repository to experiment with, please read enough of
the Cederqvist manual to find out how to create one. Set your <TT>CVSROOT</TT>
environment variable to point to your repository and you are ready to
explore Meta-CVS.
<A NAME="@default2"></A><BR>
<BR>
In this guide, a few typographic conventions are used. Text which
is stored into or produced by the computer is written in <TT>typewriter</TT>
font. The first mention of any special terms is <I>italicized</I>. Such terms
are, for your convenience, gathered into a glossary in the appendix.<BR>
<BR>
<!--TOC section Tutorial-->

<H2><A NAME="htoc2">2</A>&nbsp;&nbsp;Tutorial</H2><!--SEC END -->

In this section, you will learn how to place a directory tree of files under
version control, check out that tree to create a working copy (also called a
<I>sandbox</I>), make changes in the sandbox and store the changes in the
repository. A directory of files independently versioned under Meta-CVS
is called a <I>module</I>, because it is represented as a CVS 
module.<SUP><A NAME="text1" HREF="#note1">1</A></SUP>
<A NAME="@default3"></A>
<A NAME="@default4"></A>
<A NAME="@default5"></A>
<A NAME="@default6"></A><BR>
<BR>
Meta-CVS has a command line interface which is deliberately similar to that of
CVS. The program's name is <TT>mcvs</TT>. The <TT>mcvs</TT> program takes a 
variety of arguments. The first argument is usually a word which specifies
a command. Oft used commands have two-letter abbreviations. For example the
<TT>update</TT> command, whose abbreviation is <TT>up</TT>, 
causes material in the repository to be integrated into the working copy.<BR>
<BR>
Before the first argument, one may type special options. These are called
global options, and they influence the behavior of many commands in a similar
way. For example, when communicating with a remote repository over a slow
network, the <TT>-z</TT> option may be used to specify a compression level.
<A NAME="@default7"></A>
 <A NAME="@default8"></A>
<!--TOC subsection Creating a Module-->

<H3><A NAME="htoc3">2.1</A>&nbsp;&nbsp;Creating a Module</H3><!--SEC END -->

<A NAME="@default9"></A>
 <A NAME="@default10"></A>
The only way to create a module is to start with an existing directory 
containing files and subdirectories, and invoke the <TT>create</TT> command.
Suppose that your project is a compiler for a scripting language called Blorg,
and you want your module to be called <TT>blorg</TT>. First, change to
the directory containing your latest Blorg sources:
<A NAME="@default11"></A>
<PRE>
    cd blorg-devel
</PRE>Then, invoke the command:
<PRE>
    mcvs create blorg blorg-initial-version
</PRE>The <TT>create</TT> command requires two additional arguments: the name of
the module, and a symbolic name which will identify the baseline of
newly versioned files. This name is known as a <I>tag</I>: more specificaly, a
<I>version tag</I>. Here, we have chosen the tag <TT>blorg-initial-version</TT>.
Tags are very useful when one makes a module from a specific version of an
existing program. Suppose that you didn't write Blorg yourself; rather, you
have a copy of the Blorg 2.3 sources and would like to begin your own
independent stream of development. It would then behoove you, when creating the
module, to use a tag like <TT>blorg-2-3</TT>. This tag could prove to be very
important later on; for example, when you want to create a branch from the 2.3
baseline, which will accept a new snapshot from the Blorg developers.
<A NAME="@default12"></A>
<A NAME="@default13"></A><BR>
<BR>
The first action that the <TT>create</TT> command takes is to scan the current
working directory, and, recursively, all of its subdirectories. It forms
a list of all regular files and symbolic links, ignoring any other
types of files such as sockets, devices, pipes and the like. Having thus
gathered a list of the files, it identifies all of their <I>suffixes</I> and
collates them to form a list. <BR>
<BR>
If none of the files have suffixes, the creation procedure skips to the next
step. Otherwise, a text editor is invoked in order to allow you to make
alterations to a specification which tells how files having these various
suffixes are to be treated when they are stored into and retrieved from CVS.
The specification is written in the <I>Lisp</I> language, and may look
something like this:
<A NAME="@default14"></A>
<PRE>
    (("c" :DEFAULT)
     ("lisp" :DEFAULT)
     ("png" :DEFAULT)
     ("txt" :DEFAULT))
</PRE>This is the notation for a list of four elements, as indicated by the
outermost parentheses which enclose the whole thing. Each of the four
elements is itself a list containing a string like <TT>"c"</TT> and the
symbol <TT>:DEFAULT</TT>. The string represents a file suffix, and the
symbol indicates how files having that suffix are to be treated.
Above the list, you should see a comment explaining the
various keywords which are supported. The greatest concern is to
identify what files are binary. For example, in the above definition,
the treatment of the suffix <TT>.png</TT> should be modified to <TT>:BINARY</TT>
<A NAME="@default15"></A>
<A NAME="@default16"></A>
because most likely this suffix indicates a computer graphics image
in the Portable Network Graphics format, which is a binary format
that must not be subject to line ending conversions, nor to keyword expansion.
When you are done editing, save and quit; Meta-CVS will then proceed.
If you create a syntax error, for example by introducing an unbalanced
parenthesis, Meta-CVS will prompt you with an error message, and you will
be given an opportunity to correct the error in a new text editing session.
<A NAME="@default17"></A><BR>
<BR>
Note that the symbols may be typed in any mixture of upper and lower
case---<TT>:Binary</TT>, <TT>:binary</TT>, <TT>:BiNaRy</TT>, and so forth. These
all mean the same thing. However, the leading colon is required.<SUP><A NAME="text2" HREF="#note2">2</A></SUP><BR>
<BR>
Finally, Meta-CVS invokes CVS to create a new module in the repository.
CVS also starts a text editor. This time you are expected to enter
a log message which will be added to version 1.1 of every new document.
You are, in fact, interacting with <TT>cvs import</TT>.
<A NAME="@default18"></A><BR>
<BR>
<!--TOC subsection Checking out a Module-->

<H3><A NAME="htoc4">2.2</A>&nbsp;&nbsp;Checking out a Module</H3><!--SEC END -->

Like CVS, and some other version control systems, Meta-CVS is based on sandbox
model. Under this model, documents are copied from a central repository, and users
work with copies of documents. Obtaining a copy is called checking out.
The Meta-CVS command for checking out is <TT>checkout</TT>, abbreviated <TT>co</TT>.
<A NAME="@default19"></A>
 <A NAME="@default20"></A>It takes one argument. Continuing with our Blorg example:
<PRE>
    mcvs co blorg
</PRE>After a log of messages scrolls by in the terminal window, there should
now exist the subdirectory <TT>blorg</TT>, and in that subdirectory there
should appear the project's source files. This is a working copy, or a sandbox.
You can check out more than one sandbox; sometimes that is convenient to do
when one needs to work on several completely unrelated tasks in the same
project. The CVS repository doesn't know anything about your sandbox; rather,
each sandbox contains information which points back to the repository from
which it was checked out. It is safe to move the sandbox by applying the <TT>mv</TT> command to its root directory.
<A NAME="@default21"></A><BR>
<BR>
<!--TOC subsection Anatomy of a Sandbox-->

<H3><A NAME="htoc5">2.3</A>&nbsp;&nbsp;Anatomy of a Sandbox</H3><!--SEC END -->

In the root directory of the sandbox, as you will probably notice, there is a
subdirectory called <TT>MCVS</TT>. This is where Meta-CVS stores its local
administrative files as well as versioned metadata. It is also where your
documents are checked out from CVS; effectively, this directory doubles as a
CVS sandbox.
<A NAME="@default22"></A><BR>
<BR>
All your files have been assigned machine-generated names by Meta-CVS.
These names begin with the characters <TT>F-</TT> followed by thirty-two
hexadecimal digits and an optional suffix. In Meta-CVS jargon, they are called
<I>F-files</I>. These files are connected to the directory structure of
the sandbox through <I>hard links</I>. 
<A NAME="@default23"></A>
That is to say, each of the F-files 
which appears under the <TT>MCVS</TT> directory also exists in some other
directory within your sandbox. This arrangement is possible because your
operating system allows a file object to be referenced by more than one
directory entry. Directories are nothing more than lists which link names to
file objects. The same file can be known as <TT>MCVS/F-0AA69D7C8A0A864345D90F45C18B8B58</TT> as well as <TT>source/lib/hash.c</TT>. In
order to delete the file from your filesystem, you have to delete both
directory entries.<SUP><A NAME="text3" HREF="#note3">3</A></SUP>
<A NAME="@default25"></A><BR>
<BR>
When you check out a module, Meta-CVS calls upon CVS to retrieve
copies of F-files from the repository. Then it re-creates the directory
structure of the sandbox, inserting these files in the appropriate places
in that structure under their familiar names. This insertion is not done
by copying the F-files, but rather by creating links to them, which
is very efficient. <BR>
<BR>
How does Meta-CVS remember the familar names of the F-files so that it can
construct the sandbox? This association is recorded in a file called <TT>MAP</TT>
under the <TT>MCVS</TT> directory, represented in Lisp notation. You are going
to have to understand the <TT>MAP</TT> file sooner or later, because at times it
is necessary to manually edit that file. For example, it can happen that
several programmers independently change the mapping in a way that creates a
conflict. Resolving the conflict means loading the file into a text editor, and
manually sorting out the problem.
<A NAME="@default26"></A><BR>
<BR>
Why does Meta-CVS assigns its own internal names to files, and stores
the user-assigned names in a special versioned document? The reason
is to make it possible to perform directory structure versioning,
which means that the directory structure of a module is versioned just
like the contents of its files. Changing the name or location of
a file is effectively just another edit that is commited to the repository.<BR>
<BR>
Symbolic links are represented purely as special entries in the tt MAP file;
their contents are not versioned in CVS as independent objects.<BR>
<BR>
<!--TOC subsection Making Changes-->

<H3><A NAME="htoc6">2.4</A>&nbsp;&nbsp;Making Changes</H3><!--SEC END -->

Now that you have a working copy checked out, you are probably eager
to make some changes. This is quite easy; simply edit any of the
files to your satisfaction. The version control system knows that you
have edited the files; when you are ready, you can instruct
the software to publish your changes to the repository. Publishing
changes is known as <I>committing</I> and is performed using the <TT>commit</TT>
command, abbreviated <TT>ci</TT>:<SUP><A NAME="text4" HREF="#note4">4</A></SUP>
<A NAME="@default28"></A>
 <A NAME="@default29"></A><PRE>
    mcvs ci
</PRE>A text editor starts up, and you are expected to enter a commit comment.
You are interacting with CVS at this point; the procedure is exactly the
same as for CVS commits. However, there is one notable difference. The file names
you see listed in the usual comment lines which begin with <TT>CVS:</TT> and which
will be removed are the F-file names, rather than the human-readable
names. Alas, CVS doesn't know about the mapping, and this text
is prepared within the innards of CVS! Meta-CVS has a solution, though not an entirely
satisfactory one, in the form of a text filtering command which
reads arbitrary text on standard input, and copies it to standard output,
filtering F-file names to their human-readable counterparts. This command
is <TT>filt</TT>, abbreviated&nbsp;<TT>fi</TT>. 
<A NAME="@default30"></A>
 <A NAME="@default31"></A>Decent text editors allow portions of the text to be easily filtered through
an external command. For example, in the vi editor, the command 
<TT>:%!mcvs fi</TT> command will apply the Meta-CVS filter to the entire edit
buffer. It's trivial to bind this this command to a control character, and
store this definition in the editor's personal configuration file, so that the
action can be repeated by typing one or two keystrokes.<BR>
<BR>
<!--TOC subsection Adding Files-->

<H3><A NAME="htoc7">2.5</A>&nbsp;&nbsp;Adding Files</H3><!--SEC END -->

Some kinds of changes require special steps to inform Meta-CVS of
your intent. For example, if you decide to add some files, Meta-CVS
will not automatically incorporate them into the module. For obvious
reasons, a sandbox is allowed to contain a mixture of local files and
versioned files; there is no certain way to tell which local files ought
to be versioned. An object file which results from compiling source
code almost certainly does not belong under version control, whereas a
new source file probably does. Or does it? It may be a temporary module
introduced for debugging, or some experimental code. Only the programmer
knows whether it ought to be published to the repository. Every file that
is added under version control initially starts out as a local file. An
explicit <TT>add</TT> command must be invoked to cause a local file to become
versioned. The effect of <TT>add</TT> is a local change until it is committed to
the repository.<BR>
<BR>
<A NAME="@default32"></A>
 <A NAME="@default33"></A>The add command requires additional arguments which specify what files are to
be added. For exaple, to add the local files <TT>macros.lisp</TT> and <TT>README</TT>, issue the command:
<PRE>
    mcvs add macros.lisp README
</PRE>Unlike CVS, Meta-CVS allows you to add entire subdirectories at a time.
The arguments can be any mixture of files and subdirectories; however,
subdirectories are only added if the <TT>-R</TT> option is specified.
For example, to add the directories <TT>sources</TT>, <TT>documentation</TT>
and the file <TT>INSTALL</TT>.
<PRE>
    mcvs add -R sources documentation INSTALL
</PRE><A NAME="@default34"></A>
 <A NAME="@default35"></A>Like the <TT>create</TT> command, the <TT>add</TT> command scans the files and
symbolic links to be added, and computes a list of the suffixes of the files.
If any hitherto unknown suffixes are discovered, a text editor will
be invoked to allow you to specify the treatment of these files.
The effect of <TT>mcvs add</TT> is local; the files aren't incorporated
into the repository until a commit takes place.<BR>
<BR>
<!--TOC subsection Reviewing Changes-->

<H3><A NAME="htoc8">2.6</A>&nbsp;&nbsp;Reviewing Changes</H3><!--SEC END -->

Before committing local changes, one usually wants to review what those changes
are; to find out what files have been added, removed, moved or modified, and to
view the differences in modified files. The <TT>status</TT>, or <TT>stat</TT>
command, invoked without any arguments, produces a listing of all modified
files in the current directory and its subdirectories. To include the
meta-data files such as <TT>MAP</TT>, use the <TT>--meta</TT> global option.
<A NAME="@default36"></A>
 <A NAME="@default37"></A><A NAME="@default38"></A>
 <A NAME="@default39"></A><A NAME="@default40"></A>
The output of <TT>status</TT> contains F-file names, so the <TT>filt</TT> command
comes in handy. And of course the <TT>grep</TT> utility is useful in reducing
the output to include information only about locally modified files:
<A NAME="@default41"></A> 
<PRE>
    mcvs --meta status | grep Modified | mcvs fi         # list modified files
    mcvs status | grep Added | mcvs fi                   # list added files
</PRE>The <TT>status</TT> command takes optional filename and directory arguments.
The status of a directory means all of the files in its tree.<BR>
<BR>
Another useful command is <TT>diff</TT> which views differences between revisions,
or between the locally modified files and their closest repository revisions.
Like <TT>stat</TT>, <TT>diff</TT> responds to the <TT>--meta</TT> global option,
works on the current directory by default, and takes optional file name or
directory arguments. It supports a large number of options which affect
the way the differences are computed and presented. The two most useful are
<TT>-u</TT> which produces a more readable, so-called ``unified'' diff,
and <TT>-b</TT> which suppresses differences in whitespace, which is particularly
useful when a few small coding changes in a program gives rise to a big
change in indentation. For example,
<A NAME="@default42"></A>
 <A NAME="@default43"></A><A NAME="@default44"></A>
 <A NAME="@default45"></A><A NAME="@default46"></A>
 <A NAME="@default47"></A><PRE>
    mcvs diff -ub driver.c
</PRE>shows the modifications in driver.c as a unified diff, treating lines
that differ only in the amount of whitespace as identical.<BR>
<BR>
<!--TOC subsection Error Recovery-->

<H3><A NAME="htoc9">2.7</A>&nbsp;&nbsp;Error Recovery</H3><!--SEC END -->

The execution of a Meta-CVS command can encounter a problem situation,
or error. For example, suppose that one user adds and commits a file
called <TT>parser.c</TT> and then another user performs an update to pull
the latest material from the repository. Suppose that the other user
already has a local file called <TT>parser.c</TT>. This is identified
by Meta-CVS as a problem. There are at least two ways of dealing with
this problem. One is to defer the problem: do nothing at all and
just terminate, leaving the effect of the update operation incomplete.
The next time <TT>mcvs up</TT> is invoked, it will run into the problem again, if
the local file still exists. The user has a chance to rename the file
``out of the way'' and re-try the update. A possible resolution is to 
overwrite the local file with the one from the repository.<BR>
<BR>
Errors are divided into two categories: terminating errors and continuable
errors. When a terminating errors occurs, Meta-CVS display as error message,
and terminates. Termination is always graceful; if some operation is partially
done, the partial effects are undone. A continuable error, by contrast,
causes Meta-CVS to prompt the user with a menu of choices.<BR>
<BR>
<!--TOC section Glossary-->

<H2><A NAME="htoc10">A</A>&nbsp;&nbsp;Glossary</H2><!--SEC END -->

<!--TOC paragraph baseline-->

<H5>baseline</H5><!--SEC END -->
 A crosscut through a collection of version-controlled
documents, which selects a specific version of each document.
<A NAME="@default48"></A><BR>
<BR>
<!--TOC paragraph basename-->

<H5>basename</H5><!--SEC END -->
 The short name of a file, excluding the full path,
if any. For example, the basename of <TT>src/lib/lexer.c</TT> is <TT>lexer.c</TT>.
<A NAME="@default49"></A><BR>
<BR>
<!--TOC paragraph commit-->

<H5>commit</H5><!--SEC END -->
 To publish local changes to the repository, thereby
permanently integrating them into the project history. Commited changes
can be picked up in other sandboxes by <I>update</I>.<BR>
<BR>
<!--TOC paragraph CVS-->

<H5>CVS</H5><!--SEC END -->
 Concurrent Versions System. A popular freeware version control
suite widely used by free software projects. CVS started as a set of shell
scripts written by Dick Grune, who posted the software to Usenet in 1986.
Grune's CVS scripts used RCS; they provided higher-level functionality over
RCS, automating and simplifying the use of RCS by for instance applying version
control operations such as merging to entire sets of files at once.
Eventually, CVS was rewritten in C, and directly incorporated the algorithms
from RCS while remaining compatible with the RCS file format. 
<A NAME="@default50"></A><BR>
<BR>
<!--TOC paragraph F-file-->

<H5>F-file</H5><!--SEC END -->
 A user document stored by Meta-CVS, in CVS, having a
machine-generated name consisting of the characters <TT>F-</TT> followed
by thirty-two hexadecimal digits and an optional suffix.
<A NAME="@default51"></A><BR>
<BR>
<!--TOC paragraph hard link-->

<H5>hard link</H5><!--SEC END -->
 An association connecting a directory entry to a file
object.
<A NAME="@default52"></A><BR>
<BR>
<!--TOC paragraph Lisp-->

<H5>Lisp</H5><!--SEC END -->
 <B>1.</B> The standard computing language <I>ANSI Common
Lisp</I>. <B>2.</B> Printed notation, conforming to the ANSI Common Lisp syntax,
expressing a potentially complex, nested data structure. <B>3.</B> Program code
resulting from the reinterpretation of Lisp data structures as programming
language constructs.
<A NAME="@default53"></A><BR>
<BR>
<!--TOC paragraph module-->

<H5>module</H5><!--SEC END -->
 An independent set of documents managed as a unit using
Meta-CVS.
<A NAME="@default54"></A><BR>
<BR>
<!--TOC paragraph sandbox-->

<H5>sandbox</H5><!--SEC END -->
 The working copy of a module.
<A NAME="@default55"></A><BR>
<BR>
<!--TOC paragraph stream-->

<H5>stream</H5><!--SEC END -->
 An independent line of development, represented in
the version control system as an independent history of changes.
In Meta-CVS, there is a main history known as the trunk. Secondary histories
are called branches.
<A NAME="@default56"></A><BR>
<BR>
<!--TOC paragraph suffix-->

<H5>suffix</H5><!--SEC END -->
 The trailing portion of a <I>basename</I> which is separated
from the rest of the name by a period (.) character. If there are two or
more such characters, then it is the longest such portion. If the basename
contains no periods, then it has no suffix. If the basename begins with a
period, the rest of that entire name is a suffix. Examples:
the suffix of <TT>lint.tar.gz</TT> is <TT>tar.gz</TT>; that of <TT>.xshell.rc</TT>
is <TT>xshell.rc</TT>; the suffix of <TT>foo.</TT> is the empty string; and neither
<TT>.clisprc</TT> nor <TT>README</TT> have a suffix.
<A NAME="@default57"></A><BR>
<BR>
<!--TOC paragraph tag-->

<H5>tag</H5><!--SEC END -->
 A symbolic revision which identifies a <I>baseline</I>. Tags
are used by disciplined developers, or configuration managers, to label
software releases so that it is possible to later retrieve the exact baseline
of any given release.
<A NAME="@default58"></A><BR>
<BR>
<!--TOC paragraph update-->

<H5>update</H5><!--SEC END -->
 In CVS parlance, to retrieve a version of one or more
documents from the repository, merge it with local changes made to the sandbox
copy, if any, and then replace that copy. Updating is not only used to
incorporate the latest changes from the repository into a sandbox, while
preserving any outstanding local modifications, but it is also used for
``navigating'' to old versions and switching among branches.<BR>
<BR>
<A NAME="@default59"></A>
<!--TOC section Index-->

<H2>Index</H2><!--SEC END -->


<TABLE CELLSPACING=2 CELLPADDING=0>
<TR><TD VALIGN=top ALIGN=left><UL><LI>
<TT>--meta</TT> option, <A HREF="#@default36">2.6</A>
<LI><TT>-b</TT> option
<UL><LI>
of <TT>diff</TT>, <A HREF="#@default46">2.6</A>
</UL>
<LI><TT>-R</TT> option
<UL><LI>
of <TT>add</TT>, <A HREF="#@default34">2.5</A>
</UL>
<LI><TT>-u</TT> option
<UL><LI>
of <TT>diff</TT>, <A HREF="#@default44">2.6</A>
</UL>
<LI><TT>-z</TT> option, <A HREF="#@default7">2</A>
<BR>
<BR>
<LI><TT>add</TT> command, <A HREF="#@default32">2.5</A>
<LI>
<UL><LI>
<TT>-R</TT> option, <A HREF="#@default35">2.5</A>
</UL>
<BR>
<BR>
<LI>Blorg, <A HREF="#@default11">2.1</A>
<LI>baseline, <A HREF="#@default13">2.1</A>, <A HREF="#@default48">A</A>
<LI>basename, <A HREF="#@default49">A</A>
<LI><TT>:binary</TT>, <A HREF="#@default15">2.1</A>
<BR>
<BR>
<LI>Cederqvist, <A HREF="#@default1">1</A>
<LI>CVS, <A HREF="#@default50">A</A>

<UL><LI>
<TT>import</TT> command, <A HREF="#@default18">2.1</A>
</UL>
<LI><TT>CVSROOT</TT>, <A HREF="#@default2">1</A>
<LI><TT>checkout</TT> command, <A HREF="#@default19">2.2</A>
<LI>commands
<UL><LI>
<TT>add</TT>, <A HREF="#@default33">2.5</A>
<LI><TT>checkout</TT>, <A HREF="#@default20">2.2</A>
<LI><TT>commit</TT>, <A HREF="#@default29">2.4</A>
<LI><TT>create</TT>, <A HREF="#@default10">2.1</A>
<LI><TT>diff</TT>, <A HREF="#@default43">2.6</A>
<LI><TT>filt</TT>, <A HREF="#@default31">2.4</A>
<LI><TT>status</TT>, <A HREF="#@default39">2.6</A>
</UL>
<LI><TT>commit</TT> command, <A HREF="#@default28">2.4</A>
<LI><TT>create</TT> command, <A HREF="#@default9">2.1</A>
<BR>
<BR>
<LI><TT>:default</TT>, <A HREF="#@default16">2.1</A>
<LI><TT>diff</TT> command, <A HREF="#@default42">2.6</A>
<LI>
<UL><LI>
<TT>-b</TT> option, <A HREF="#@default47">2.6</A>
<LI><TT>-u</TT> option, <A HREF="#@default45">2.6</A>
</UL>
</UL></TD>
<TD VALIGN=top ALIGN=left><UL><LI>F-file, <A HREF="#@default25">2.3</A>, <A HREF="#@default51">A</A>
<LI><TT>filt</TT> command, <A HREF="#@default30">2.4</A>
<BR>
<BR>
<LI>global options
<UL><LI>
<TT>--meta</TT>, <A HREF="#@default37">2.6</A>
<LI><TT>-z</TT>, <A HREF="#@default8">2</A>
</UL>
<LI>grep, <A HREF="#@default41">2.6</A>
<BR>
<BR>
<LI>hard link, <A HREF="#@default23">2.3</A>, <A HREF="#@default52">A</A>
<BR>
<BR>
<LI>Lisp, <A HREF="#@default14">2.1</A>, <A HREF="#@default53">A</A>
<BR>
<BR>
<LI><TT>MAP</TT> file, <A HREF="#@default26">2.3</A>, <A HREF="#@default40">2.6</A>
<LI><TT>MCVS</TT> subdirectory, <A HREF="#@default22">2.3</A>
<LI><TT>mcvs</TT> program, <A HREF="#@default5">2</A>
<LI>module, <A HREF="#@default4">2</A>, <A HREF="#@default54">A</A>
<LI>moving
<UL><LI>
a sandbox, <A HREF="#@default21">2.2</A>
</UL>
<BR>
<BR>
<LI><TT>png</TT> files, <A HREF="#@default17">2.1</A>
<BR>
<BR>
<LI>RCS, <A HREF="#@default27">2.4</A>
<LI>renaming, see <I>moving</I>
<BR>
<BR>
<LI>sandbox, <A HREF="#@default3">2</A>, <A HREF="#@default55">A</A>
<LI><TT>status</TT> command, <A HREF="#@default38">2.6</A>
<LI>stream, <A HREF="#@default0">1</A>, <A HREF="#@default56">A</A>
<LI>suffix, <A HREF="#@default57">A</A>
<BR>
<BR>
<LI>tag, <A HREF="#@default12">2.1</A>, <A HREF="#@default58">A</A>
<BR>
<BR>
<LI><TT>unlink</TT> 
system function, <A HREF="#@default24">2.3</A>
<BR>
<BR>
<LI>working copy, see <I>sandbox</I>
</UL></TD>
</TR></TABLE>
<!--BEGIN NOTES document-->
<HR WIDTH="50%" SIZE=1><DL><DT><A NAME="note1" HREF="#text1"><FONT SIZE=5>1</FONT></A><DD>But note that unlike CVS, Meta-CVS does not support 
the model of combining modules.
<DT><A NAME="note2" HREF="#text2"><FONT SIZE=5>2</FONT></A><DD>In
case you are interested, that colon is a special Lisp notation which indicates
that the following name refers to a symbol in the <TT>KEYWORD</TT> package.
<DT><A NAME="note3" HREF="#text3"><FONT SIZE=5>3</FONT></A><DD>This is why the POSIX system function for doing
this is called <TT>unlink</TT>. Deleting a directory entry doesn't necessarily
mean that a file is gone, only that a link, possibly not the last remaining
link, has been erased. <A NAME="@default24"></A>
<DT><A NAME="note4" HREF="#text4"><FONT SIZE=5>4</FONT></A><DD>This stands for check in,
which means the same thing as commit in the jargon of the RCS version control
system. RCS has a <TT>ci</TT> command, and this abbreviation survived into
CVS.<A NAME="@default27"></A>
</DL>
<!--END NOTES-->
<!--HTMLFOOT-->
<!--ENDHTML-->
<!--FOOTER-->
<HR SIZE=2>
<BLOCKQUOTE><EM>This document was translated from L<sup>A</sup>T<sub>E</sub>X by
</EM><A HREF="http://pauillac.inria.fr/~maranget/hevea/index.html"><EM>H<FONT SIZE=2><sup>E</sup></FONT>V<FONT SIZE=2><sup>E</sup></FONT>A</EM></A><EM>.
</EM></BLOCKQUOTE>
</BODY>
</HTML>