/[meta-cvs]/meta-cvs/F-8F7DAF614BB613A14BEA23D9E52482F5.latex
ViewVC logotype

Contents of /meta-cvs/F-8F7DAF614BB613A14BEA23D9E52482F5.latex

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.6.4.4 - (hide annotations)
Wed Dec 31 06:40:00 2003 UTC (10 years, 3 months ago) by kaz
Branch: mcvs-1-0-branch
CVS Tags: mcvs-1-0-branch~merged-to-HEAD-1, mcvs-1-0-branch~merged-to-HEAD-0, mcvs-1-0-11, mcvs-1-0-10, mcvs-1-0-13, mcvs-1-0-12
Changes since 1.6.4.3: +2 -2 lines
File MIME type: application/x-latex
Spelling fix.
1 kaz 1.1 \documentclass{article}
2 kaz 1.2 \usepackage{makeidx}
3     \usepackage[margin=1.0in]{geometry}
4    
5 kaz 1.5 \def\cvsrelease$#1: mcvs-#2-#3 ${#2.#3}
6 kaz 1.3 \def\cvsdate$#1: #2/#3/#4 #5 ${#2-#3-#4}
7 kaz 1.1
8 kaz 1.2 \def\indexcommand#1
9     {\index{#1@{\tt #1} command}
10     \index{commands!#1@{\tt #1}}}
11 kaz 1.1
12 kaz 1.2 \def\indexglobalopt#1
13     {\index{#1@{\tt #1} option}
14     \index{global options!#1@{\tt #1}}}
15 kaz 1.1
16 kaz 1.4 \def\indexcommandopt#1#2
17     {\index{#2 option@{\tt #2} option!of #1@of {\tt #1}}
18     \index{#1 command@ !#2 option@{\tt #2} option}}
19    
20 kaz 1.6.4.3 \title{Version Control with Meta-CVS \cvsrelease$Name: $}
21 kaz 1.6.4.4 \date{\cvsdate$Date: 2003/07/16 05:36:55 $}
22 kaz 1.1 \author{Kaz Kylheku}
23 kaz 1.2 \makeindex
24    
25     \begin{document}
26 kaz 1.1 \maketitle
27 kaz 1.2 \tableofcontents
28    
29     \section{Introduction}
30     Greetings, reader! You are about to become a user of version control software
31 kaz 1.6 called Meta-CVS. The primary function of version control software is to store
32     multiple versions of a group of documents, such as the source files of a
33     computer program. As programmers make changes to the program, they generate
34     new versions of source files, which are retained in the version control system.
35     They may also add files, delete files, rename files, reshape the directory
36     structure of the project; the history of these changes is also retained,
37     just are the changes to the contents of the files themselves.
38    
39     In addition, to be useful, a version control system must not only store file
40     versions but it must be able to identify groups of related versions, so that an
41     old version of the entire project can be retrieved as a unit. For example,
42     when the programmers decide to release the program, they must be able to assign
43     a symbolic name to the release, and that name must be associated with a
44     particular version of every file. This will allow the release to be later
45     retrieved using its symbolic name as a retrieval key.
46    
47     Secondly, a version control system must allow developers to make changes in
48     parallel to the same line (or {\it stream}) of development, and merge their
49     changes.
50     \index{stream}
51     It must identify conflicting changes so that they can be resolved. In must also
52     allow for multiple parallel lines of development---independent version
53     histories known as branches. Branches are useful for stabilizing software prior
54     to the current release, while allowing new development to happen on the
55     next release. They are useful for going back to an old release and fixing
56     errors. They are also useful for isolating risky, experimental work. When such
57     work involves many changes or more than one developer, it can take place on its
58     own branch. A good version control system makes it easy to create branches, and
59     to merge new changes from the branch back to the original stream.
60    
61     Meta-CVS is not a fully self-contained version control system. It uses another
62     version control system called CVS to store documents, and also to store
63     additional information about documents which allows it to provide useful
64     behaviors that do not exist in CVS. Effectively, Meta-CVS acts as an agent
65     between you and CVS, which is easier to use and more capable than CVS.
66 kaz 1.2
67     I wrote Meta-CVS because I was frustrated by the inability of CVS to treat the
68 kaz 1.6 directory structures of my projects as a versioned entity. At the same time, I
69 kaz 1.2 did not want to rewrite everything that already works well in CVS, such as
70     client-server operation, maintaining file version histories, and branching,
71     merging and conflict identification. Instead, I decided to write a software
72 kaz 1.6 layer which uses CVS as a foundation. That software layer would not only do
73     completely new things, like directory structure versioning, but also to
74     automate certain tedious tasks which are normally performed with great
75 kaz 1.2 difficulty by the users of CVS.
76    
77     Meta-CVS does not, and is not intended to, entirely shield you from knowing
78     anything about CVS. Firstly, Meta-CVS requires the CVS software and a CVS
79     repository. Users who want to use Meta-CVS have to know how to obtain and
80     install CVS and create a repository. Moreover, from time to time it is useful
81     or necessary to bypass Meta-CVS and invoke a CVS operation directly. This
82     guide does not teach CVS; you are strongly encouraged to read {\it Version
83     Management with CVS\/} by Per Cederqvist et al. \index{Cederqvist}
84    
85     If you do not have a CVS repository to experiment with, please read enough of
86     the Cederqvist manual to find out how to create one. Set your {\tt CVSROOT}
87     environment variable to point to your repository and you are ready to
88     explore Meta-CVS.
89     \index{CVSROOT@{\tt CVSROOT}}
90    
91     In this guide, a few typographic conventions are used. Text which
92     is stored into or produced by the computer is written in {\tt typewriter}
93     font. The first mention of any special terms is {\it italicized}. Such terms
94     are, for your convenience, gathered into a glossary in the appendix.
95    
96     \section{Tutorial}
97    
98     In this section, you will learn how to place a directory tree of files under
99     version control, check out that tree to create a working copy (also called a
100     {\it sandbox}), make changes in the sandbox and store the changes in the
101     repository. A directory of files independently versioned under Meta-CVS
102     is called a {\it module}, because it is represented as a CVS
103     module.\footnote{But note that unlike CVS, Meta-CVS does not support
104     the model of combining modules.}
105     \index{sandbox}
106     \index{module}
107     \index{mcvs program@{\tt mcvs} program}
108     \index{working copy|see {sandbox}}
109    
110     Meta-CVS has a command line interface which is deliberately similar to that of
111     CVS. The program's name is {\tt mcvs}. The {\tt mcvs} program takes a
112     variety of arguments. The first argument is usually a word which specifies
113     a command. Oft used commands have two-letter abbreviations. For example the
114     {\tt update} command, whose abbreviation is {\tt up},
115     causes material in the repository to be integrated into the working copy.
116    
117     Before the first argument, one may type special options. These are called
118     global options, and they influence the behavior of many commands in a similar
119     way. For example, when communicating with a remote repository over a slow
120     network, the {\tt -z} option may be used to specify a compression level.
121     \indexglobalopt{-z}
122    
123     \subsection{Creating a Module}
124     \indexcommand{create}
125    
126     The only way to create a module is to start with an existing directory
127     containing files and subdirectories, and invoke the {\tt create} command.
128     Suppose that your project is a compiler for a scripting language called Blorg,
129     and you want your module to be called {\tt blorg}. First, change to
130     the directory containing your latest Blorg sources:
131     \index{Blorg}
132     \begin{verbatim}
133     cd blorg-devel
134     \end{verbatim}
135     Then, invoke the command:
136     \begin{verbatim}
137     mcvs create blorg blorg-initial-version
138     \end{verbatim}
139     The {\tt create} command requires two additional arguments: the name of
140     the module, and a symbolic name which will identify the baseline of
141     newly versioned files. This name is known as a {\it tag}: more specificaly, a
142     {\it version tag}. Here, we have chosen the tag {\tt blorg-initial-version}.
143     Tags are very useful when one makes a module from a specific version of an
144     existing program. Suppose that you didn't write Blorg yourself; rather, you
145     have a copy of the Blorg 2.3 sources and would like to begin your own
146     independent stream of development. It would then behoove you, when creating the
147     module, to use a tag like {\tt blorg-2-3}. This tag could prove to be very
148     important later on; for example, when you want to create a branch from the 2.3
149     baseline, which will accept a new snapshot from the Blorg developers.
150     \index{tag}
151     \index{baseline}
152    
153     The first action that the {\tt create} command takes is to scan the current
154     working directory, and, recursively, all of its subdirectories. It forms
155 kaz 1.6.4.1 a list of all regular files and symbolic links, ignoring any other
156     types of files such as sockets, devices, pipes and the like. Having thus
157     gathered a list of the files, it identifies all of their {\it suffixes} and
158     collates them to form a list.
159 kaz 1.2
160     If none of the files have suffixes, the creation procedure skips to the next
161     step. Otherwise, a text editor is invoked in order to allow you to make
162     alterations to a specification which tells how files having these various
163     suffixes are to be treated when they are stored into and retrieved from CVS.
164     The specification is written in the {\it Lisp\/} language, and may look
165     something like this:
166     \index{Lisp}
167     \begin{verbatim}
168     (("c" :DEFAULT)
169     ("lisp" :DEFAULT)
170     ("png" :DEFAULT)
171     ("txt" :DEFAULT))
172     \end{verbatim}
173     This is the notation for a list of four elements, as indicated by the
174     outermost parentheses which enclose the whole thing. Each of the four
175     elements is itself a list containing a string like {\tt "c"} and the
176     symbol {\tt :DEFAULT}. The string represents a file suffix, and the
177     symbol indicates how files having that suffix are to be treated.
178 kaz 1.6.4.1 Above the list, you should see a comment explaining the
179 kaz 1.2 various keywords which are supported. The greatest concern is to
180     identify what files are binary. For example, in the above definition,
181     the treatment of the suffix {\tt .png} should be modified to {\tt :BINARY}
182     \index{binary@{\tt :binary}}
183     \index{default@{\tt :default}}
184     because most likely this suffix indicates a computer graphics image
185     in the Portable Network Graphics format, which is a binary format
186     that must not be subject to line ending conversions, nor to keyword expansion.
187     When you are done editing, save and quit; Meta-CVS will then proceed.
188     If you create a syntax error, for example by introducing an unbalanced
189     parenthesis, Meta-CVS will prompt you with an error message, and you will
190     be given an opportunity to correct the error in a new text editing session.
191     \index{png files@{\tt png} files}
192    
193     Note that the symbols may be typed in any mixture of upper and lower
194     case---{\tt :Binary}, {\tt :binary}, {\tt :BiNaRy}, and so forth. These
195     all mean the same thing. However, the leading colon is required.\footnote{In
196     case you are interested, that colon is a special Lisp notation which indicates
197     that the following name refers to a symbol in the {\tt KEYWORD} package.}
198    
199     Finally, Meta-CVS invokes CVS to create a new module in the repository.
200 kaz 1.6.4.1 CVS also starts a text editor. This time you are expected to enter
201 kaz 1.2 a log message which will be added to version 1.1 of every new document.
202     You are, in fact, interacting with {\tt cvs import}.
203     \index{CVS!import command@{\tt import} command}
204    
205     \subsection{Checking out a Module}
206    
207     Like CVS, and some other version control systems, Meta-CVS is based on sandbox
208     model. Under this model, documents are copied from a central repository, and users
209     work with copies of documents. Obtaining a copy is called checking out.
210     The Meta-CVS command for checking out is {\tt checkout}, abbreviated {\tt co}.
211     \indexcommand{checkout}
212     It takes one argument. Continuing with our Blorg example:
213     \begin{verbatim}
214     mcvs co blorg
215     \end{verbatim}
216     After a log of messages scrolls by in the terminal window, there should
217     now exist the subdirectory {\tt blorg}, and in that subdirectory there
218     should appear the project's source files. This is a working copy, or a sandbox.
219     You can check out more than one sandbox; sometimes that is convenient to do
220     when one needs to work on several completely unrelated tasks in the same
221     project. The CVS repository doesn't know anything about your sandbox; rather,
222     each sandbox contains information which points back to the repository from
223     which it was checked out. It is safe to move the sandbox by applying the {\tt
224     mv} command to its root directory.
225     \index{moving!a sandbox}
226    
227     \subsection{Anatomy of a Sandbox}
228    
229     In the root directory of the sandbox, as you will probably notice, there is a
230     subdirectory called {\tt MCVS}. This is where Meta-CVS stores its local
231     administrative files as well as versioned metadata. It is also where your
232     documents are checked out from CVS; effectively, this directory doubles as a
233     CVS sandbox.
234     \index{MCVS subdirectory@{\tt MCVS} subdirectory}
235    
236     All your files have been assigned machine-generated names by Meta-CVS.
237     These names begin with the characters {\tt F-} followed by thirty-two
238     hexadecimal digits and an optional suffix. In Meta-CVS jargon, they are called
239     {\it F-files}. These files are connected to the directory structure of
240     the sandbox through {\it hard links}.
241     \index{hard link}
242     That is to say, each of the F-files
243 kaz 1.6.4.1 which appears under the {\tt MCVS} directory also exists in some other
244 kaz 1.2 directory within your sandbox. This arrangement is possible because your
245     operating system allows a file object to be referenced by more than one
246     directory entry. Directories are nothing more than lists which link names to
247     file objects. The same file can be known as {\tt
248     MCVS/F-0AA69D7C8A0A864345D90F45C18B8B58} as well as {\tt source/lib/hash.c}. In
249     order to delete the file from your filesystem, you have to delete both
250     directory entries.\footnote{This is why the POSIX system function for doing
251     this is called {\tt unlink}. Deleting a directory entry doesn't necessarily
252     mean that a file is gone, only that a link, possibly not the last remaining
253     link, has been erased. \index {unlink system function@{\tt unlink}
254     system function}}
255     \index{F-file}
256    
257     When you check out a module, Meta-CVS calls upon CVS to retrieve
258     copies of F-files from the repository. Then it re-creates the directory
259     structure of the sandbox, inserting these files in the appropriate places
260     in that structure under their familiar names. This insertion is not done
261     by copying the F-files, but rather by creating links to them, which
262     is very efficient.
263    
264     How does Meta-CVS remember the familar names of the F-files so that it can
265     construct the sandbox? This association is recorded in a file called {\tt MAP}
266     under the {\tt MCVS} directory, represented in Lisp notation. You are going
267     to have to understand the {\tt MAP} file sooner or later, because at times it
268     is necessary to manually edit that file. For example, it can happen that
269     several programmers independently change the mapping in a way that creates a
270     conflict. Resolving the conflict means loading the file into a text editor, and
271     manually sorting out the problem.
272     \index{MAP file@{\tt MAP} file}
273    
274     Why does Meta-CVS assigns its own internal names to files, and stores
275     the user-assigned names in a special versioned document? The reason
276     is to make it possible to perform directory structure versioning,
277     which means that the directory structure of a module is versioned just
278     like the contents of its files. Changing the name or location of
279     a file is effectively just another edit that is commited to the repository.
280    
281 kaz 1.6.4.1 Symbolic links are represented purely as special entries in the {tt MAP} file;
282     their contents are not versioned in CVS as independent objects.
283    
284 kaz 1.2 \subsection{Making Changes}
285    
286     Now that you have a working copy checked out, you are probably eager
287     to make some changes. This is quite easy; simply edit any of the
288     files to your satisfaction. The version control system knows that you
289     have edited the files; when you are ready, you can instruct
290     the software to publish your changes to the repository. Publishing
291     changes is known as {\it committing\/} and is performed using the {\tt commit}
292     command, abbreviated {\tt ci}:\footnote{This stands for check in,
293     which means the same thing as commit in the jargon of the RCS version control
294     system. RCS has a {\tt ci} command, and this abbreviation survived into
295     CVS.\index{RCS}}
296     \indexcommand{commit}
297     \begin{verbatim}
298     mcvs ci
299     \end{verbatim}
300     A text editor starts up, and you are expected to enter a commit comment.
301     You are interacting with CVS at this point; the procedure is exactly the
302     same as for CVS commits. However, there is one notable difference. The file names
303     you see listed in the usual comment lines which begin with {\tt CVS:} and which
304     will be removed are the F-file names, rather than the human-readable
305     names. Alas, CVS doesn't know about the mapping, and this text
306     is prepared within the innards of CVS! Meta-CVS has a solution, though not an entirely
307     satisfactory one, in the form of a text filtering command which
308     reads arbitrary text on standard input, and copies it to standard output,
309     filtering F-file names to their human-readable counterparts. This command
310     is {\tt filt}, abbreviated~{\tt fi}.
311     \indexcommand{filt}
312     Decent text editors allow portions of the text to be easily filtered through
313     an external command. For example, in the vi editor, the command
314     {\tt :\%!mcvs fi} command will apply the Meta-CVS filter to the entire edit
315     buffer. It's trivial to bind this this command to a control character, and
316     store this definition in the editor's personal configuration file, so that the
317     action can be repeated by typing one or two keystrokes.
318    
319     \subsection{Adding Files}
320    
321     Some kinds of changes require special steps to inform Meta-CVS of
322     your intent. For example, if you decide to add some files, Meta-CVS
323     will not automatically incorporate them into the module. For obvious
324     reasons, a sandbox is allowed to contain a mixture of local files and
325     versioned files; there is no certain way to tell which local files ought
326     to be versioned. An object file which results from compiling source
327     code almost certainly does not belong under version control, whereas a
328     new source file probably does. Or does it? It may be a temporary module
329     introduced for debugging, or some experimental code. Only the programmer
330     knows whether it ought to be published to the repository. Every file that
331     is added under version control initially starts out as a local file. An
332     explicit {\tt add} command must be invoked to cause a local file to become
333 kaz 1.6.4.1 versioned. The effect of {\tt add} is a local change until it is committed to
334     the repository.
335 kaz 1.2
336     \indexcommand{add}
337 kaz 1.6.4.1 The add command requires additional arguments which specify what files are to
338     be added. For exaple, to add the local files {\tt macros.lisp} and {\tt
339     README}, issue the command:
340 kaz 1.2 \begin{verbatim}
341     mcvs add macros.lisp README
342     \end{verbatim}
343     Unlike CVS, Meta-CVS allows you to add entire subdirectories at a time.
344     The arguments can be any mixture of files and subdirectories; however,
345     subdirectories are only added if the {\tt -R} option is specified.
346     For example, to add the directories {\tt sources}, {\tt documentation}
347     and the file {\tt INSTALL}.
348     \begin{verbatim}
349     mcvs add -R sources documentation INSTALL
350     \end{verbatim}
351 kaz 1.4 \indexcommandopt{add}{-R}
352 kaz 1.6.4.1 Like the {\tt create} command, the {\tt add} command scans the files and
353     symbolic links to be added, and computes a list of the suffixes of the files.
354     If any hitherto unknown suffixes are discovered, a text editor will
355     be invoked to allow you to specify the treatment of these files.
356 kaz 1.2 The effect of {\tt mcvs add} is local; the files aren't incorporated
357     into the repository until a commit takes place.
358    
359     \subsection{Reviewing Changes}
360    
361     Before committing local changes, one usually wants to review what those changes
362     are; to find out what files have been added, removed, moved or modified, and to
363 kaz 1.4 view the differences in modified files. The {\tt status}, or {\tt stat}
364     command, invoked without any arguments, produces a listing of all modified
365     files in the current directory and its subdirectories. To include the
366     meta-data files such as {\tt MAP}, use the {\tt --meta} global option.
367     \indexglobalopt{--meta}
368     \indexcommand{status}
369     \index{MAP file@{\tt MAP} file}
370     The output of {\tt status} contains F-file names, so the {\tt filt} command
371     comes in handy. And of course the {\tt grep} utility is useful in reducing
372     the output to include information only about locally modified files:
373     \index{grep}
374     \begin{verbatim}
375     mcvs --meta status | grep Modified | mcvs fi # list modified files
376     mcvs status | grep Added | mcvs fi # list added files
377     \end{verbatim}
378     The {\tt status} command takes optional filename and directory arguments.
379     The status of a directory means all of the files in its tree.
380    
381     Another useful command is {\tt diff} which views differences between revisions,
382     or between the locally modified files and their closest repository revisions.
383     Like {\tt stat}, {\tt diff} responds to the {\tt --meta} global option,
384     works on the current directory by default, and takes optional file name or
385     directory arguments. It supports a large number of options which affect
386     the way the differences are computed and presented. The two most useful are
387     {\tt -u} which produces a more readable, so-called ``unified'' diff,
388     and {\tt -b} which suppresses differences in whitespace, which is particularly
389     useful when a few small coding changes in a program gives rise to a big
390     change in indentation. For example,
391     \indexcommand{diff}
392     \indexcommandopt{diff}{-u}
393     \indexcommandopt{diff}{-b}
394     \begin{verbatim}
395     mcvs diff -ub driver.c
396     \end{verbatim}
397     shows the modifications in driver.c as a unified diff, treating lines
398     that differ only in the amount of whitespace as identical.
399    
400     \subsection{Error Recovery}
401    
402 kaz 1.6.4.1 The execution of a Meta-CVS command can encounter a problem situation,
403     or error. For example, suppose that one user adds and commits a file
404     called {\tt parser.c} and then another user performs an update to pull
405     the latest material from the repository. Suppose that the other user
406     already has a local file called {\tt parser.c}. This is identified
407     by Meta-CVS as a problem. There are at least two ways of dealing with
408     this problem. One is to defer the problem: do nothing at all and
409     just terminate, leaving the effect of the update operation incomplete.
410     The next time {\tt mcvs up} is invoked, it will run into the problem again, if
411     the local file still exists. The user has a chance to rename the file
412     ``out of the way'' and re-try the update. A possible resolution is to
413     overwrite the local file with the one from the repository.
414    
415     Errors are divided into two categories: terminating errors and continuable
416     errors. When a terminating errors occurs, Meta-CVS display as error message,
417 kaz 1.6.4.4 and terminates. Termination is always graceful; if some operation is partially
418 kaz 1.6.4.1 done, the partial effects are undone. A continuable error, by contrast,
419     causes Meta-CVS to prompt the user with a menu of choices.
420 kaz 1.2
421    
422     \appendix
423    
424     \section{Glossary}
425    
426     \paragraph{baseline} A crosscut through a collection of version-controlled
427     documents, which selects a specific version of each document.
428     \index{baseline}
429    
430 kaz 1.6.4.1 \paragraph{basename} The short name of a file, excluding the full path,
431 kaz 1.2 if any. For example, the basename of {\tt src/lib/lexer.c} is {\tt lexer.c}.
432     \index{basename}
433    
434     \paragraph{commit} To publish local changes to the repository, thereby
435     permanently integrating them into the project history. Commited changes
436     can be picked up in other sandboxes by {\it update}.
437    
438     \paragraph{CVS} Concurrent Versions System. A popular freeware version control
439     suite widely used by free software projects. CVS started as a set of shell
440     scripts written by Dick Grune, who posted the software to Usenet in 1986.
441     Grune's CVS scripts used RCS; they provided higher-level functionality over
442     RCS, automating and simplifying the use of RCS by for instance applying version
443     control operations such as merging to entire sets of files at once.
444     Eventually, CVS was rewritten in C, and directly incorporated the algorithms
445     from RCS while remaining compatible with the RCS file format.
446     \index{CVS}
447    
448     \paragraph{F-file} A user document stored by Meta-CVS, in CVS, having a
449     machine-generated name consisting of the characters {\tt F-} followed
450     by thirty-two hexadecimal digits and an optional suffix.
451     \index{F-file}
452    
453     \paragraph{hard link} An association connecting a directory entry to a file
454     object.
455     \index{hard link}
456    
457     \paragraph{Lisp} {\bf 1.} The standard computing language {\it ANSI Common
458     Lisp}. {\bf 2.} Printed notation, conforming to the ANSI Common Lisp syntax,
459     expressing a potentially complex, nested data structure. {\bf 3.} Program code
460     resulting from the reinterpretation of Lisp data structures as programming
461     language constructs.
462     \index{Lisp}
463    
464     \paragraph{module} An independent set of documents managed as a unit using
465     Meta-CVS.
466     \index{module}
467    
468 kaz 1.6.4.1 \paragraph{sandbox} The working copy of a module.
469 kaz 1.2 \index{sandbox}
470 kaz 1.6
471     \paragraph{stream} An independent line of development, represented in
472     the version control system as an independent history of changes.
473     In Meta-CVS, there is a main history known as the trunk. Secondary histories
474     are called branches.
475     \index{stream}
476 kaz 1.2
477     \paragraph{suffix} The trailing portion of a {\it basename} which is separated
478     from the rest of the name by a period (.) character. If there are two or
479     more such characters, then it is the longest such portion. If the basename
480     contains no periods, then it has no suffix. If the basename begins with a
481     period, the rest of that entire name is a suffix. Examples:
482     the suffix of {\tt lint.tar.gz} is {\tt tar.gz}; that of {\tt .xshell.rc}
483     is {\tt xshell.rc}; the suffix of {\tt foo.} is the empty string; and neither
484     {\tt .clisprc} nor {\tt README} have a suffix.
485     \index{suffix}
486    
487     \paragraph{tag} A symbolic revision which identifies a {\it baseline}. Tags
488     are used by disciplined developers, or configuration managers, to label
489     software releases so that it is possible to later retrieve the exact baseline
490     of any given release.
491     \index{tag}
492    
493     \paragraph{update} In CVS parlance, to retrieve a version of one or more
494     documents from the repository, merge it with local changes made to the sandbox
495     copy, if any, and then replace that copy. Updating is not only used to
496     incorporate the latest changes from the repository into a sandbox, while
497     preserving any outstanding local modifications, but it is also used for
498     ``navigating'' to old versions and switching among branches.
499 kaz 1.1
500 kaz 1.2 \index{renaming|see {moving}}
501     \printindex
502 kaz 1.1 \end{document}

  ViewVC Help
Powered by ViewVC 1.1.5