d/freebsd-skq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
freebsd-skq/gnu/usr.bin/cvs/FAQ

7827 lines
271 KiB
Plaintext
Raw Normal View History

Original sources from CVS-1.4A2 munged to fit our directory structure.
1995-03-31 07:45:34 +00:00
Archive-name: cvs-faq
$Revision: 1.1 $ <<== Include this in your comments
$Date: 1994/10/07 06:17:45 $
===========================================================================
== Frequently Asked Questions about CVS (The Concurrent Versions System) ==
===========================================================================
This document attempts to answer questions posed by users of CVS.
CVS installers, administrators and maintainers looking for info on
system setup should read the section entitled "Installing CVS".
Disclaimer:
Though every attempt has been made to ensure the veracity of the
following material, no responsibility is assumed for any use, or
for any consequences resulting from any use, of the information
contained herein. No guarantee of suitability for any purpose
is offered or implied. Nothing in this document may be assumed
to represent the employers of its contributors.
I also might have slipped in a whopper or two to see if you are
paying attention. ;-) In other words, don't bet the house on
anything you read here unless you have checked it out yourself.
Send questions and answers (along with additions to, subtractions
from, and divisions of existing questions -- no multiplications,
square roots, or transcendental functions, my cabinet is full of them)
to the author, who wrote all unattributed text: (Does it always
feel strange to refer to oneself in the third person?)
David G. Grubbs <dgg@think.com>
To help readers of previous versions of this document, I will annotate
each question with a change marker
Change markers: Column 1 will contain a:
'-' for a Question that has changed.
'=' for an Answer that has changed.
'#' for an entry with changes to both Question and Answer.
'+' for a newly added Question and Answer.
The markers indicate significant changes in content between major
revision numbers. Trivial changes, such as question reordering or
spelling and grammar corrections are not marked. If I need to delete
a question, I'll move it to a "Deleted" section for a few revisions.
Deletions will arise when new versions of CVS are released. In the
long run, any question that can be answered by "get the latest
release" will be deleted.
The minor revision number will change frequently. If a minor revision
change is large enough, I'll add a change marker. At major revision
changes the markers will be cleared and set again, based on the latest
minor revision of the previous major revision.
Editorial comments are delimited by pairs of "[[" & "]]". They
contain either references to the (usually unfinished) nature of the
FAQ entry itself or version-specific comments to be removed (or
altered) when new revisions of CVS are released.
You may redistribute this as long as you don't take statements out
of context. Keep it together along with the revision number.
============================================
== Section 0 ==== Introduction ====
============================================
The questions in this document come from many sources in many forms. Some
are simple, some verbose. A few are difficult, but all of them have been
asked of the author at one time or another. Some questions are really
three or more different problems rolled into one plaintive cry for help.
Others reveal one of the bugs or weaknesses of CVS.
CVS addresses some difficult problems to which there are no perfect
solutions. CVS also changes over time as new features are required.
Therefore, the questions are about a complicated moving target.
Though in most cases I've tried to provide the simplest answer I can
think of, some of the *questions* are difficult to follow. If you
aren't using CVS regularly, don't expect to understand everything.
A Frequently Asked Questions document is not a substitute for the man page
or any other documentation. It is an attempt to answer questions.
You should also keep in mind that FAQs are not really intended to be
read in their entirety like a text book. You should use "grep" or
your editor's search capability to hunt for keywords and read the
sections you need.
Questions are divided into five numbered Sections. Sections are divided
into lettered sub-sections. The questions are numbered sequentially
within each sub-section, though they are in no particular order.
1. What is CVS?
A. What is CVS? What's it for? Why CVS?
B. Where do I find it? Where can I find Help?
C. How does CVS differ from other similar software?
D. What do you mean by . . .? (Definitions)
2. User Tasks
A. Getting Started
B. Common User Tasks
C. Less Common User Tasks
D. General Questions
3. Commands
A. through P. One section for each CVS command.
4. Advanced Topics
A. Installing CVS
B. Setting up and Managing the Repository
C. Branching
D. Tricks of the Trade
E. Weirdness
F. Related Software
G. Other Systems
5. Past & Future
A. Contributors.
B. Bugs and Patches
C. Development
6. Table of Contents
Final note:
Except for the "Past & Future" section, all answers in this
document refer to the latest released version of CVS: 1.3.
============================================
== Section 1 ==== What is CVS? ====
============================================
----------------
-- Section 1A -- What is CVS? What's it for? Why CVS?
----------------
**** Questions:
1A.1 What does CVS stand for? Can you describe it in one sentence?
1A.2 What is CVS for? What does it do for me?
1A.3 How does CVS work?
=1A.4 What is CVS useful for?
=1A.5 What is CVS *not* useful for?
=1A.6 Why isn't it called OSCO (Online Source COntrol)?
**** Answers:
1A.1 What does CVS stand for? Can you describe it in one sentence?
"CVS" is an acronym for the "Concurrent Versions System".
CVS is a "Source Control" or "Revision Control" tool
designed to keep track of changes to files made by groups of
developers working on the same files, allowing them to
stay in sync with each other as each individual chooses.
1A.2 What is CVS for? What does it do for me?
CVS is used to keep track of collections of files in a shared
directory, called "The Repository". Each collection of files
can be given a "module" name, which is used to "checkout"
that collection.
After checkout, files can be modified (using your favorite
editor), "committed" back into the Repository and compared
against earlier revisions. Collections of files can be
"tagged" with a symbolic name for later retrieval.
You can add new files, remove files you no longer want, ask for
information about sets of files in three different ways,
produce patch "diffs" from a base revision and merge the
committed changes of other developers into your working files.
1A.3 How does CVS work?
CVS stores its files in a directory hierarchy, called the
Repository, which is separate from the user's working directory.
Files in the Repository are stored in a format dictated by the
RCS commands CVS uses to do much of its real work. RCS files
are standard byte-stream files with an internal format described
by keywords stored in the files themselves.
To begin work, you execute the "checkout" command, handing it
a module or directory you want to work on. CVS copies each file
in the specified module or directory out of the Repository and
into a sub-directory created in your current directory.
You may then modify files in the new sub-directory, building them
into output files and testing the results. When you want to make
your changes available to other developers, you "commit" them back
into the Repository.
Other developers can check out the same files at the same time.
To merge the committed work of others into your working files
you use the "update" command. When your merged files build
and test correctly, you may commit the merged result. This
method is referred to as "copy-modify-merge", which does not
require locks on the source files.
At any time, usually at some milestone, you can "tag" the
committed files, producing a symbolic name that can be handed
to a future "checkout" command. A special form of "tag"
can produce a branch in development, as usually happens at
"release" time.
When you no longer plan to modify or refer to your local copy
of the files, they can be removed.
=1A.4 What is CVS useful for?
CVS is intended to be useful for three major activities:
1. Multiple developers
The major advantage of using CVS over the older and simpler
tools like RCS or SCCS is that it allows multiple developers
to work on the same sources at the same time.
The shared Repository provides a rendezvous point for
committed sources that allows developers a fair amount of
flexibility in how often to publish (via the "commit"
command) changes or include work committed by others (via the
"update" command).
2. Vendor releases
If you are making changes to a product distributed by someone
else, the CVS feature, called the Vendor Branch, allows you
to combine local modifications with vendor releases.
I have found this most useful when dealing with sources from
three major classes of source vendor:
a. Large companies who send you tapes full of the latest
release (e.g. Unix OS vendors, database companies).
b. Public Domain software which *always* requires work.
c. Pseudo-Public sources which require medium amounts of
work. (e.g. GNU programs, X, etc.)
3. Branches
Aside from the "Vendor Branch", there are three kinds of
"branches in development" that CVS can support:
a. Your working directory can be treated as a private branch.
b. A Development branch can be shared by one or more developers.
c. At release time, a branch is usually created for bug fixes.
(See 1D.9 and Section 4C for more info on branches.)
Although, at this writing, CVS's branch support is a bit
primitive, CVS was designed to allow you to create branches,
work on them for while and merge them back into the main
line of development. Arbitrary sharing and merging between
branches is not currently supported.
=1A.5 What is CVS *not* useful for?
CVS is not a build system.
Though the structure of your Repository and modules file
interact with your build system (e.g. Makefiles), they are
essentially independent.
CVS does not dictate how you build anything. It merely stores
files for retrieval in a tree structure you devise.
CVS does not dictate how to use disk space in the checked
out working directories. If you write your Makefiles or
scripts in every directory so they have to know the relative
positions of everything else, you wind up requiring the entire
Repository to be checked out. That's simply bad planning.
If you modularize your work, and construct a build system
that will share files (via links, mounts, VPATH in Makefiles,
etc.), you can arrange your disk usage however you like.
But you have to remember that *any* such system is a lot of
work to construct and maintain. CVS does not address the
issues involved. You must use your brain and a collection
of other tools to provide a build scheme to match your plans.
Of course, you should place the tools created to support such
a build system (scripts, Makefiles, etc) under CVS.
CVS is not a substitute for management.
Your managers and project leaders are expected to talk to
you frequently enough to make certain you are aware of
schedules, merge points, branch names and release dates. If
they don't, CVS can't help.
CVS is an instrument for making sources dance to your tune.
But you are the piper and the composer. No instrument plays
itself or writes its own music.
CVS is not a substitute for developer communication.
When faced with conflicts within a single file, most
developers manage to resolve them without too much effort.
But a more general definition of "conflict" includes problems
too difficult to solve without communication between
developers.
CVS cannot determine when simultaneous changes within a single
file, or across a whole collection of files, will logically
conflict with one another. Its concept of a "conflict" is
purely textual, arising when two changes to the same base file
are near enough to spook the merge (i.e. "diff3") command.
CVS does not claim to help at all in figuring out non-textual
or distributed conflicts in program logic.
For example: Say you change the arguments to function X
defined in file A. At the same time, someone edits file B,
adding new calls to function X using the old arguments. You
are outside the realm of CVS's competence.
Acquire the habit of reading specs and talking to your peers.
CVS is not a configuration management system.
CVS is a source control system. The phrase "configuration
management" is a marketing term, not an industry-recognized
set of functions.
A true "configuration management system" would contain
elements of the following:
* Source control.
* Dependency tracking.
* Build systems (i.e. What to build and how to find
things during a build. What is shared? What is local?)
* Bug tracking.
* Automated Testing procedures.
* Release Engineering documentation and procedures.
* Tape Construction.
* Customer Installation.
* A way for users to run different versions of the same
software on the same host at the same time.
CVS provides only the first.
=1A.6 Why isn't it called OSCO (Online Source COntrol)?
Better discount? CVS is shorter? (The international audience
requires an explanation: Both CVS and OSCO are the names of large
chains of Pharmacies (drug stores) in the U.S.)
----------------
-- Section 1B -- Where do I find CVS? Where can I find Help?
----------------
**** Questions:
1B.1 How do I get more information about CVS?
1B.2 Is there an archive of CVS material?
1B.3 How do I get a copy of the latest version of CVS?
1B.4 Is there any other documentation? How about tutorials?
1B.5 Is there a mailing list devoted to CVS? How do I get on it?
1B.6 What prayers are appropriate for each of the major denominations
(e.g. 20's, 50's, 100's) when issuing complex CVS commands?
+1B.7 How do I get files out of the archive if I don't have FTP?
**** Answers:
=1B.1 How do I get more information about CVS?
1. The first thing you should do is read the man page.
2. Type "cvs -H" for general help or "cvs -H command" for
command-specific help.
3. Read the original CVS paper (in the source tree, under "doc").
It describes the purpose of CVS and some of its workings. Note
that some of the emphasis (especially on multiple vendors
providing the same sources) is out of date.
4. Read the man pages for RCS.
5. Read the source code.
6. Look in the "doc" directory in the FTP archive described
below.
7. Read the gnu.cvs.info newsgroup.
8. If you don't get the newsgroup, you can join the info-cvs
mailing list, described below.
1B.2 Is there an archive of CVS material?
An anonymous FTP area has been set up. It contains many of the
CVS files you might want, including documentation, patches and
the latest release.
ftp think.com
>>> User: anonymous
>>> Passwd: <Your Internet address>
cd /pub/cvs
get README
get Index
The README has more (and more up-to-date) information. The Index
contains a terse list of what is in the archive.
+1B.3 How do I get files out of the archive if I don't have FTP?
Use one of the FTP<->Email servers. These are the ones
I've been told about:
1. To use DEC's ftpmail service, type
echo 'send help' | mail ftpmail@decwrl.dec.com
which will send you a message telling you how to use Email to
retrieve files from FTP archives.
2. If you are on BITNET, use Princeton's BITFTP server. Type
echo 'send help' | mail bitftp@pucc.princeton.edu
(It is likely that only BITNET addresses can use this one.)
3. Other possibilities I've heard of from the net:
(Try the one closest to you.)
ftpmail@sunsite.unc.edu
ftpmail@cs.arizona.edu
ftpmail@cs.uow.edu.au
ftpmail@doc.ic.ac.uk
1B.4 How do I get a copy of the latest version of CVS?
The latest released version of CVS and all the programs it
depends on should be available through anonymous FTP on any FSF
archive. The main FSF archive is at "prep.ai.mit.edu". There is
another archive at UUNET and other large Internet sites.
Program(s) Latest revision
----------- -----------------------
CVS 1.3
RCS 5.6.0.1
GNU diff 2.3
The GNU version of diff is suggested by both the RCS and CVS
configuration instructions because it works better than the
standard version. If you plan to use dbm in the modules file, you
might also want to pick up the GNU dbm library.
It is a good idea not to accept the versions of CVS, RCS or diff
you find lying on your system unless you have checked out their
provenance. Using inconsistent collections of tools can cause you
more trouble than you probably want.
The FTP archive mentioned above should contain the latest official
release of CVS, some official and unofficial patches and possibly
complete patched versions of CVS in use somewhere.
1B.5 Is there any other documentation? How about tutorials?
Take a look at the "doc" sub-directory in the FTP archive.
You should find a growing collection of additional CVS
documentation there.
Other sources:
1. Per Cederqvist's Texinfo manual.
The latest version of the Texinfo manual written by Per
Cederqvist is included in the "doc" area mentioned
above.
2. Gray Watson's cvs_tutorial.
There is a version of this document in the "doc" area.
3. Apparently there is at least one project at O'Reilly (on
RCS/SCCS) that will include some info about CVS.
[[Anything else?]]
#1B.6 Is there a mailing list or Usenet newsgroup devoted to CVS?
How do I find them?
An Internet mailing list named "info-cvs" grew out of the private
mailing list used by the CVS 1.3 alpha testers in early 1992. An
associated Usenet newsgroup named "gnu.cvs.info" was created in
August, 1993.
The newsgroup and the mailing list are bidirectionally gatewayed,
meaning that you only need access to one of them. Anything sent
to the mailing list will be automatically posted to "gnu.cvs.info"
and anything posted to the newsgroup will be automatically mailed
to "info-cvs".
First try the newsgroup, since it is generally easier to read (and
manage) than a mailing list. Ask your system administrator
whether you get the "gnu" hierarchy. If so, select a newsreader
and dive in.
If you don't get any form of Usenet News (or don't get the "gnu"
hierarchy), you can add yourself to the mailing list by sending an
Email message to:
info-cvs-request@prep.ai.mit.edu
(Don't forget the "-request" or you'll send a message to the
whole list, some of whom are capable of remote execution.)
Mail to the whole list should be sent to:
info-cvs@prep.ai.mit.edu
An archive of the mailing list and the newsgroup might appear
someday in the CVS FTP archive.
1B.7 What prayers are appropriate for each of the major denominations
(e.g. 20's, 50's, 100's) when issuing complex CVS commands?
Only what the traffic will allow, in small, unmarked bills
delivered to me, Ralph Icebag, in a plain brown wrapper, by a
brown-shoed square, in the dead of night. (Apologies to
Firesign Theater.)
----------------
-- Section 1C -- How does CVS differ from other similar software?
----------------
This section attempts to list programs purporting to cover some of the
same territory as CVS. [[These are very sparsely documented here. If you
know something about one of these tools, how about trying to flesh out an
entry or two?]]
**** Questions:
=1C.1 How does CVS differ from RCS?
1C.2 How does CVS differ from SCCS?
=1C.3 How does CVS differ from ClearCase?
=1C.4 How does CVS differ from TeamWare?
1C.5 How does CVS differ from SunPro?
1C.6 How does CVS differ from Aegis?
1C.7 How does CVS differ from Shapetools?
+1C.8 How does CVS differ from TeamNet?
+1C.9 How does CVS differ from ProFrame?
+1C.10 How does CVS differ from CaseWare/CM?
+1C.11 How does CVS differ from Sublime?
**** Answers:
=1C.1 How does CVS differ from RCS?
CVS uses RCS to do much of its work and absolutely all the work
of changing the underlying RCS files in the Repository.
RCS comprises a set of programs designed to keep track of changes
to individual files. Of course, it also allows you to refer to
whole sets of files on the command line, but groups are
manipulated by iterating over those files. There is no pretense
of combined interaction between the files.
CVS's main intent is to provide a set of grouping functions that
allow you to treat a collection of RCS files as a single object.
Of course, CVS also has to do a lot of iteration, but it tries
its best to hide that it is doing so. In addition, CVS has some
truly group-oriented facets, such as the modules file and the CVS
administrative files that refer to a whole directory or module.
One group aspect that can be a bit confusing is that a CVS branch
is not the same as an RCS branch. To support a CVS branch, CVS
uses "tags" (what RCS calls "symbols") and some local state,
in addition to RCS branches.
Other features offered by CVS that are not supported directly by
RCS are
1. Automatic determination of the state of a file, (e.g.
modified, up-to-date with the Repository, already tagged
with the same string, etc.) which helps in limiting the
amount of displayed text you have to wade through to
figure out what changed and what to do next.
2. A copy-modify-merge scheme that avoids locking the files
and allows simultaneous development on a single file.
3. Serialization of commits. CVS requires you to merge all
changes committed (via "update") since you checked out
your working copy of the file. Although it is still
possible to commit a file filled with old data, it is less
likely than when using raw RCS.
4. Relatively easy merging of releases from external Vendors.
1C.2 How does CVS differ from SCCS?
SCCS is much closer to RCS than to CVS, so some of the previous
entry applies.
You might want to take a look at Walter Tichy's papers on RCS,
which are referred to in the RCS man pages.
[[More info here?]]
=1C.3 How does CVS differ from ClearCase?
ClearCase is a client-server CASE tool for version management,
configuration management, and process management. ClearCase
is an evolution of the popular DSEE tools, formerly available
on HP/Apollo platforms. ClearCase includes an X/Motif GUI,
command-line interface, and C programmer API, and is currently
available on Sun, HP, and SGI platforms.
ClearCase uses a special Unix filesystem type, called "mfs"
for "multi-version file system". Conceptually, mfs adds
another dimension to the regular Unix filesystem. The new
axis is used to store the different versions of files. Each
user makes a "view" into the file database by creating a
special mfs mountpoint on their machine. Each view has a set
of flexible selection rules that specify the particular
version of each file to make visible in that view. You can
think of a "view" as a workarea in CVS, except that the files
don't really exist on your local disk until you modify them.
This type of filesystem is sometimes called "copy-on-write"
and conserves disk space for files that are read-only.
Another advantage is that a view is "tranparent" in the sense
that all of the files in a "view" appear to be regular Unix
files to other tools and Unix system calls. An extended
naming convention allows access to particular versions of a
file directly: "test.cc@@/main/bugfix/3" identifies the third
version of test.c on the bugfix branch.
ClearCase supports both the copy-modify-merge model of CVS and
the checkin/checkout development model with file locking.
Directories are versionable objects as well as files. A
graphical n-way merge tool is provided. Like CVS, ClearCase
supports branches, symbolic tags, and delta compression.
ASCII as well as binary files are supported, and converters
from RCS, SCCS, DSEE formats are also included.
A make-compatible build facility is provided that can identify
common object code and share it among developers. A build
auditing feature automatically records file dependencies by
tracking every file that is opened when producing a derived
object, thus making explicit Makefiles unnecessary. Pre- and
post-event triggers are available for most ClearCase
operations to invoke user programs or shell scripts.
User-defined attributes can be assigned to any version or
object. Hyperlinks between versioned objects can record their
relationship.
For more information, contact:
Atria Software, Inc.
24 Prime Park Way
Natick, MA 01760
info@atria.com
(508) 650-1193 (phone)
(508) 650-1196 (fax)
Contributed by Steve Turner
[extracted from the ClearCase 1.1.1 documentation]
=1C.4 How does CVS differ from TeamWare?
TeamWare is a configuration management tool from Sun
Microsystems.
For more information, contact:
SunExpress, Inc.
P.O. Box 4426
Bridgeton, MO 63044-9863
(800)873-7869
1C.5 How does CVS differ from SunPro?
SunPro is advertised as the successor to "SCCS".
[[Need more info here.]]
1C.6 How does CVS differ from Aegis?
Aegis appears to be a policy-setting tool that allows you to use
other sub-programs (make, RCS, etc.) to implement pieces of the
imposed policy.
The initial document seems to say that most Unix tools are
inadequate for use under Aegis.
It is not really similar to CVS and requires a different mindset.
[[Need more info here.]]
1C.7 How does CVS differ from Shapetools?
Shapetools includes a build mechanism (called Shape, not
surprisingly) that is aware of the version mechanism, and some
dependency tracking. It is based on a file system extension
called Attributed File System, which allows arbitrary-sized
"attributes" to be associated with a file. Files are versioned in
a manner similar to RCS. Configurations are managed through the
Shapefile, an extension of the Makefile syntax and functionality.
Shape includes version selection rules to allow sophisticated
selection of component versions in a build.
Shapetools' concurrency control is pessimistic, in contrast to
that of CVS. Also, there's very limited support for branching and
merging. It has a built-in policy for transitioning a system from
initial development to production.
Contributed by Don Dwiggins
+1C.8 How does CVS differ from TeamNet?
TeamNet is a configuration management tool from TeamOne.
For more information, contact:
TeamOne
710 Lakeway Drive, Ste 100
Sunnyvale, CA 94086
(800) 442-6650
Contributed by Steve Turner
+1C.9 How does CVS differ from ProFrame?
ProFrame is a new system integration framework from IBM.
ProFrame is compliant with the CFI (CAD Framework Initiative)
industry standards, including the Scheme extension language.
ProFrame consists of three major components: (1) the Process
Manager that automates your local design methodology (2) the
Design Data Manager handles configuration management, and (3)
Inter-tool Communication to provide a communication path among
tools running on heterogeneous servers.
The Design Data Manager(2) is probably the appropriate
component to compare to CVS. The Design Data Manager provides
version control with checkin/checkout capability,
configuration management, and data dependency tracking. A
graphical data selection interface is provided. Using this
interface, you may create and manipulate objects and hierarchy
structures, view the revision history for an object, and view
and assign attributes to a design object.
The ProFrame server currently runs only on RS600, but clients
may be a wide variety of Unix platforms. Contact IBM for the
latest platform information.
For more information, contact:
IBM
EDA Marketing and Sales
P.O. Box 950, M/S P121
Poughkeepsie, NY 12602
(800) 332-0066
Contributed by Steve Turner
[extracted from the ProFrame 1.1.0 datasheet]
+1C.10 How does CVS differ from CaseWare/CM?
CaseWare/CM is a software configuration management product
from CaseWare, Inc. CaseWare/CM may be customized to support
a wide variety of methodologies, including various phases of
the software lifecycle, and different access rights for users.
A GUI is provided to view version histories and
configurations. A merge tools is also included. CaseWare
supports type-specific lifecycles, which allows different types
of files to move through different lifecycles. Also provided
is a build facility to support automatic dependency analysis,
parallel, distributed, and remote builds, and variant
releases.
CaseWare/CM has been integrated with other CASE tools,
including FrameMaker, ALSYS Ada, CodeCenter/Object Center, HP
SoftBench, and Software Through Pictures. CaseWare also
offers CaseWare/PT, a problem tracking system to integrate
change requests with configuration management.
Multiple vendors and operating systems are supported.
For more information, contact:
CaseWare, Inc.
108 Pacifica, 2nd Floor
Irvine, CA 92718-3332
(714) 453-2200 (phone)
(714) 453-2276 (fax)
Contributed by Steve Turner
[extracted from the CaseWare/CM data sheet]
+1C.11 How does CVS differ from Sublime?
Produced by AT&T.
[[Need more info here.]]
----------------
-- Section 1D -- What do you mean by . . .? (Definitions)
----------------
**** Questions:
#1D.1 What are "The Repository", "$CVSROOT" and "CVSROOT"?
1D.2 What is an RCS file?
1D.3 What is a working file?
1D.4 What is a working directory (or working area)?
1D.5 What is "checking out"?
=1D.6 What is a revision?
1D.7 What is a "Tag"?
=1D.8 What are "HEAD" and "BASE"?
=1D.9 What is a Branch?
=1D.10 What is "the trunk"?
=1D.11 What is a module?
+1D.12 What does "merge" mean?
**** Answers:
#1D.1 What are "The Repository", "$CVSROOT" and "CVSROOT"?
The Repository is a directory tree containing the CVS
administrative files and all the RCS files that constitute
"imported" or "committed" work. The Repository is kept in a
shared area, separate from the working areas of all developers.
Users of CVS must set their "CVSROOT" environment variable to the
absolute pathname of the head of the Repository. Most command
line interpreters replace an instance of "$CVSROOT" with the value
of the "CVSROOT" environment variable. By analogy, in this
document "$CVSROOT" is used as shorthand for "the absolute
pathname of the directory at the head of the Repository".
One of the things found in $CVSROOT is a directory named CVSROOT.
It contains all the "state", the administrative files, that CVS
needs during execution. The "modules", "history", "commitinfo",
"loginfo" and other files can be found there.
1D.2 What is an RCS file?
A file, usually ending in ",v", containing the source text and
the revision history for all committed revisions of a source
file. It is stored separately from the working files, in a
directory hierarchy, called the Repository.
RCS is the "Revision Control System" that CVS uses to manage
individual files.
1D.3 What is a working file?
A disk file containing a checked-out copy of a source file that
earlier had been placed under CVS. If the working file has been
edited, the changes since the last committed revision are
invisible to other users of CVS.
1D.4 What is a working directory (or working area)?
The "checkout" command creates a tree of working directories,
filling them with working files. A working directory always
contains a sub-directory named ./CVS containing information
about working files and the location of the directory within the
Repository that was used to create the working directory.
A working directory is the place where you work and the place
from which you "commit" files.
1D.5 What is "checking out"?
"Checking out" is the act of using the "checkout" command to
copy a particular revision from a set of RCS files into your
working area. See the "checkout" command in Section 3C.
=1D.6 What is a revision?
A "revision" is a version of a file that was "committed" (or
"checked in", in RCS terms) some time in the past. CVS (and
RCS) can retrieve any file that was committed by specifying its
revision number or its "tag" (or symbolic name, in RCS terms).
In CVS, a "tag" is more useful than a revision number. It usually
marks a milestone in development represented by different revision
numbers in different files, all available as one "tagged"
collection.
Sometimes the word "revision" is used as shorthand for "the file
you get if you retrieve (via "checkout" or "update") the given
revision from the Repository."
1D.7 What is a "Tag"?
A "Tag" is a symbolic name, a synonym or alias for a
particular revision number in a file. The CVS "tag" command
places the same "Tag" on all files in a working directory,
allowing you to retrieve those files by name in the future.
=1D.8 What are "HEAD" and "BASE"?
BASE and HEAD are built-in tags that don't show up in the "log"
or "status" listings. They are interpreted directly by CVS.
"HEAD" refers to the latest revision on the current branch in the
Repository. The current branch is either the main line of
development, or a branch in development created by placing a
branch tag on a set of files and checking out that branch.
"BASE" refers to the revision on the current branch you last
checked out, updated, or committed. If you have not modified
your working file, "BASE" is the committed revision matching it.
Most of the time BASE and HEAD refer to the same revision. They
become different for two reasons:
1. Someone else changed HEAD by committing a new revision of your
file to the Repository. You can pull BASE up to equal HEAD by
executing "update".
2. You moved BASE backward by executing "checkout" or "update"
with the option "-r <rev/tag>" or "-D <date>". CVS records a
sticky tag and moves your files to the specified earlier
revision. You can clear the sticky tag and pull BASE up to
equal HEAD by executing "update -A".
=1D.9 What is a Branch?
Any mechanism that allows one or more developers to modify a
physically separate copy of a file without affecting anyone other
than those working on the branch.
There are four kinds of branches CVS deals with:
1. The Vendor Branch.
A single vendor branch is supported. The "import" command
takes a sequence of releases from a source code vendor (called
a "vendor" even if no money is involved), placing them on a
special "Vendor" branch. The Vendor branch is considered part
of the "Main line" of development, though it must be merged
into locally modified files on the RCS Main branch before the
"import" is complete.
See Section 3H ("import").
2. Your Working directory.
A checked-out working directory, can be treated like a private
branch. No one but you can touch your files. You have
complete control over when you include work committed by
others. However, you can't commit or tag intermediate versions
of your work.
3. A Development branch.
A group of developers can share changes among the group,
without affecting the Main line of development, by creating a
branch. Only those who have checked-out the branch see the
changes committed to that branch. This kind of branch is
usually temporary, collapsing (i.e. merge and forget) into the
Main line when the project requiring the branch is completed.
You can also create a private branch of this type, allowing an
individual to commit (and tag) intermediate revisions without
changing the Main line. It should be managed exactly like a
Development Branch -- collapsed into the Main line and
forgotten when the work is done.
4. A Release branch.
At release time, a branch should be created marking what was
released. Later, small changes (sometimes called "patches")
can be made to the release without including everything else on
the Main line of development. You avoid forcing the customer
to accept new, possibly untested, features added since the
release. This is also the way to correct bugs found during
testing in an environment where other developers have continued
to commit to the Main line while you are testing and packaging
the release.
Although the internal format of this type of branch (branch tag
and RCS branches) is the same as in a development branch, the
purpose and the way it is managed are different. The major
difference is that the branch is Permanent. Once you let a
release out the door to customers, or to the next stage of
whatever process you are using, you should retain forever the
branch marking the release.
Since the branch is permanent, you cannot incorporate the
branch fixes into the Main line by "collapsing" (merging and
forgetting) the release branch. For large changes to many
files on the release branch, you will have to perform a branch
merge using "update -j <rev> -j <rev>". (See 4C.7)
The most common way to merge small changes back into Main line
development is to make the change in both places
simultaneously. This is faster than trying to perform a
selective merge.
See 1D.12 (merges) and Section 4C, on Branching for more info.
=1D.10 What is "the trunk"?
Another name for the RCS Main Branch. The RCS Main Branch is
related, but not equivalent, to both the CVS Main branch and what
developers consider to be the Main line of development.
See 3H.3 and Section 4C on Branching.
=1D.11 What is a module?
In essence, a module is a name you hand to the "checkout" command
to retrieve one or more files to work on. It was originally
intended to be a simple, unique name in the "modules" file
attached to a directory or a subset of files within a directory.
The module idea is now a somewhat slippery concept that can be
defined in two different ways:
A. A module is an argument to "checkout". There are three types:
1. An entry in the modules file. A "module" name as described
in 'B.' below.
2. A relative path to a directory or file in the Repository.
3. A mixed-mode string of "modulename/relative-path".
Everything up to the first slash ('/') is looked up as a
module. The relative path is appended to the directory
associated with the module name and the resulting path is
checked out as in #2 above.
B. A module is a unique (within the file) character string in the
first column of the modules file. There are five types:
1. A name for a directory within the Repository that
allows you to ignore the parent directories above it.
Example:
emacs gnu/emacs
2. A name for a subset of the files within such a directory.
Example:
ls unix/bin Makefile ls.c
The 2nd through Nth strings in the above must be *files*.
No directories, no relative pathnames. To checkout more
than one directory by a single name, use an alias as
described in #5 below.
3. A relative pathname to a directory within the Repository
which, when checked out, creates an image of part of the
Repository structure in your current directory.
Example:
gnu/emacs -o /emacs.helper gnu/emacs
The files checked out are exactly the same as the files you
would get if the path weren't even in the modules file. The
only reason to put this kind of relative pathname into the
modules file is to hook one of the helper functions onto it.
4. A relative pathname to a single file within the Repository
which, when checked out, creates something you probably
don't want: It creates a directory by the name of the file
and puts the file in it.
Example:
gnu/emacs/Makefile -o /emacs.helper gnu/emacs Makefile
The file checked out is the same as what you would get if
you handed the relative pathname to the "checkout" command.
But it puts it in a strange place. The only reason to do
this is to hook a helper function onto a specific file name.
5. An alias consisting of a list of any of the above, including
other aliases.
Example:
my_work -a emacs gnu/bison unix/bin/ls.c
Another way to look at it is that the modules file is simply
another way to "name" files. The hierarchical directory
structure provides another. You should use whatever turns out to
be simplest for your development group.
As an example, say you want to keep track of three programs, and
want to be allowed to check out any combination of one, two or all
three at a time. Here are most of the combinations I can think
of. Experiment and choose what you want -- you won't need every
possibility.
# All directories in "world", even ones added later.
world world
# All three programs by name. They checkout into local dir.
prog123 -a prog1 prog2 prog3
# All three programs by name. They checkout into "world" subdir.
wprog123 -a wprog1 wprog2 wprog3
# Individual progs checkout into dirs named "prog1", etc.
prog1 world/prog1
prog2 world/prog2
prog3 world/prog3
# Individual progs checkout into dirs named "world/prog1", etc.
wprog1 -a world/prog1
wprog2 -a world/prog2
wprog3 -a world/prog3
# Pairs that checkout into local dir.
prog12 -a prog1 prog2
prog13 -a prog1 prog3
prog23 -a prog2 prog3
# Pairs that checkout into world subdir.
# Instead of using the wprog aliases, we could use "world/prog9"
wprog12 -a wprog1 wprog2
wprog13 -a wprog1 wprog3
wprog23 -a wprog2 wprog3
+1D.12 What does "merge" mean?
A merge is a way of combining changes made in two independent
copies of the same "base" file. There are always three files
involved in a merge: the original, or "base", file and two
copies of that base file modified in different ways.
Humans aren't very good at handling three things at once, so the
terminology dealing with merges can become strained. One way to
think about it is that all merges are performed by inserting the
difference between a base revision and a later revision (committed
by someone else) into your working file. Both the "later"
revision and your working file are presumed to have started life
as a copy of the "base" revision.
In CVS, there are three main types of "merge":
1. The "update" command automatically merges revisions committed
by others into your working file. In this case, the three
files involved in the merge are:
Base: The revision you originally checked out.
Later: A revision committed onto the current branch
after you checked out the Base revision.
Working: Your working file. The one lying in the working
directory containing changes you have made.
2. The "update -j <branch_tag>" command merges a whole branch into
your working file, which is presumed to be on the Main line of
development.
See 4C.6
3. The "update -j <rev> -j <rev>" merges the difference between
two specific revisions on some other branch (though the two
revisions are usually on the same branch) into your working
directory.
See 4C.7
==========================================
== Section 2 ==== User Tasks ====
==========================================
----------------
-- Section 2A -- Getting Started
----------------
**** Questions:
2A.1 What is the first thing I have to know?
2A.2 Where do I work?
=2A.3 What does CVS use from my environment?
2A.4 OK, I've been told that CVS is set up, my module is named
"ralph" and I have to start editing. What do I type?
2A.5 I have been using RCS for a while. Can I convert to CVS without
losing my revision history? How about converting from SCCS?
**** Answers:
2A.1 What is the first thing I have to know?
Your organization has assigned one or more persons to understand,
baby-sit and administer both the CVS programs and the data
Repository. I call these persons Repository Administrators.
They will have set up a Repository and "imported" files into it.
If you don't believe anyone has this responsibility, or you are
just testing CVS, then *you* are the Repository Administrator.
If you are a normal user of CVS ask your Repository Administrator
what module you should check out.
Then you can work.
If you *are* the Repository Administrator, you will want to read
everything you can get your hands on, including this FAQ. Source
control issues can be difficult, especially when you get to
branches and release planning. Expect to feel stupid for a few
days/weeks.
No tool in the universe avoids the need for intelligent
organization. In other words, there are all sorts of related
issues you will probably have to learn. Don't expect to dive in
without any preparation, stuff your 300 Megabytes of sources into
CVS and expect to start working. If you don't prepare first, you
will probably spend a few sleepless nights.
2A.2 Where do I work?
Wherever you have disk space. That's one of the advantages of
CVS: you use the "checkout" command to copy files from the
Repository to your working directory, which can be anywhere you
have the space.
Your local group might have conventions for where to work.
Ask your peers.
=2A.3 What does CVS use from my environment?
You must set two environment variables. Some shells share these
variables with local shell variables using a different syntax.
You'll have to learn how your shell handles them.
Variable Value (or action)
--------- ---------------------
CVSROOT Absolute pathname of the head of your Repository.
PATH Normally set to a list of ':'-separated directory
pathnames searched to find executables. You must
make sure "cvs" is in one of the directories.
If your CVS installation set the RCSBIN directory
to null (""), then the RCS commands also must be
somewhere in your PATH.
Optional variables: (Used if set, but ignored otherwise.)
Variable Value (or action)
--------- ---------------------
CVSEDITOR The name of your favorite fast-start editor
program. You'll be kicked into your editor to
supply revision comments if you don't specify them
via -m "Log message" on the command line.
[Note: This is not in 1.3 -- It should appear in
the next release.]
EDITOR Used if CVSEDITOR doesn't exist. If EDITOR
doesn't exist, CVS uses a configured constant,
usually, "vi".
CVSREAD Sets files to read-only on "checkout".
RCSBIN Changes where CVS finds the RCS commands.
CVSIGNORE Adds to the ignore list. See Section 2D.
Other variables used by CVS that are normally set upon login:
Variable Value (or action)
--------- ---------------------
LOGNAME Used to find the real user name.
USER Used to find the real user name if no LOGNAME.
HOME Used to determine your home directory, if set.
Otherwise LOGNAME/USER/getuid() are used to find
your home directory from the passwd file.
2A.4 OK, I've been told that CVS is set up, my module is named
"ralph" and I have to start editing. What do I type?
cvs checkout ralph
cd ralph
And hack away.
2A.5 I have been using RCS for a while. Can I convert to CVS without
losing my revision history? How about converting from SCCS?
If you are asking such questions, you are not a mere user of CVS,
but one of its Administrators! You should take a look at Section
4A, "Installing CVS" and Section 4B, "Setting up and Managing
the Repository".
----------------
-- Section 2B -- Common User Tasks
----------------
What I consider a "common user task" generally involves combinations
of the following commands:
add, checkout, commit, diff, log, status, tag, update
Conventions in this section:
1. Before each CVS command, you are assumed to have typed a "cd"
command to move into a writable working directory.
2. All further "cd" commands specified in the examples are assumed
to start in the above working directory.
3. Unless a point is being made about multiple instances, all modules
are named <module>, all tags are named <tag> (branch tags are
named <branch_tag>) and all files are named <file>.
The checkout command will take a relative path name in place
of a module name. If you use a relative pathname in place of
<module>, you should use the same relative path every place
you see <module> in that example.
**** Questions:
#2B.1 What is the absolute minimum I have to do to edit a file?
=2B.2 If I edit multiple files, must I type "commit" for each one?
2B.3 How do I get rid of the directory that "checkout" created?
=2B.4 How do I find out what has changed?
=2B.5 I just created a new file. How do I add it to the Repository?
=2B.6 How do I merge changes made by others into my working directory?
2B.7 How do I label a set of revisions so I can retrieve them later?
2B.8 How do I checkout an old release of a module, directory or file?
2B.9 What do I have to remember to do periodically?
**** Answers:
#2B.1 What is the absolute minimum I have to do to edit a file?
Tell your Repository Administrator to create a module covering the
directory or files you care about. You'll find out that the
module name is named <module>. Then type:
cvs checkout <module>
cd <module>
emacs <file> # Isn't Emacs a synonym for editor?
cvs commit <file>
If you don't use modules (in my opinion, a mistake), you can check
out a directory by substituting its relative path within the
Repository for <module> in the example above.
To check out a single file, you'll have to change the "cd
<module>" to "cd to the parent of the file named in <module>".
=2B.2 If I edit multiple files, must I type "commit" for each one?
No. You can do them all at once by name or by directory.
See 3D.2.
2B.3 How do I get rid of the directory that "checkout" created?
Change your directory to be the same as when you executed the
"checkout" command and type:
cvs release -d <module>
The current version of CVS does not detect foreign directories
(i.e. ones that weren't created by CVS) in your working
directory and will destroy them.
If you don't care about keeping "history", and you don't care to
plan ahead to a more completely implemented "release" command, you
can just remove it. That's "rm -rf <module>" under Unix.
=2B.4 How do I find out what has changed?
There are many ways to answer this.
To find out what you've changed in your current working directory
since your last commit, type:
cvs diff
To find out what other people have added (to your branch) since
you last checked out or updated, type:
cvs diff -r BASE -r HEAD
To look at a revision history containing the comments for all
changes, you can use the "log" command.
You can also use "history" to trace a wide variety of events.
=2B.5 I just created a new file. How do I add it to the Repository?
The "update" command will display files CVS doesn't know about in
your working directory marked with a '?' indicator.
? <file>
To add <file> to the Repository, type:
cvs add <file>
cvs commit <file>
=2B.6 How do I merge changes made by others into my working directory?
If you are asking about other branches, see Section 4C on
"Branching". You will have to use the "update -j" command.
Retrieving changes made to the Repository on the *same* branch you
are working on is the main purpose of the "update" command. The
"update" command tries to merge work committed to the Repository
by others since you last executed "checkout", "update" or "commit"
into your working files.
For a single file, there are five possible results when you type
the "update" command:
1. If neither you nor others have made changes to <file>, "update"
will print nothing.
2. If you have made no changes to a file, but others have, CVS
will replace your working file with a copy of the latest
revision of that file in the Repository. You will see:
U <file>
You might want to examine the changes (using the CVS "diff"
command) to see if they mesh with your own in related files.
3. If you have made changes, but others have not, you will see:
M <file>
Nothing happened except you were told that you have a modified
file in your directory.
4. If both you and others have made changes to a file, but in
different sections of the file, CVS will merge the changes
stored in the Repository since your last "checkout", "update"
or "commit" into your working file. You will see:
RCS file: /Repository/module/<file>
retrieving revision 1.X
retrieving revision 1.Y
Merging differences between 1.X and 1.Y into <file>
M <file>
If you execute "diff" before and after this step, you should
see the same output. This is one of the few times the
otherwise nonsensical phrase "same difference" means something.
5. If both you and others have made changes to the same section of
a file, CVS will merge the changes into your file as in #4
above, but it will leave conflict indicators in the file.
You will see:
RCS file: /Repository/module/<file>
retrieving revision 1.X
retrieving revision 1.Y
Merging differences between 1.X and 1.Y into <file>
rcsmerge warning: overlaps during merge
cvs update: conflicts found in <file>
C <file>
This is a "conflict". The file will contain strange-looking
text marking the overlapping text.
You must examine the overlaps with care and resolve the
problem without removing all previous work.
2B.7 How do I label a set of revisions so I can retrieve them later?
To "tag" the BASE revisions (the ones you last checked out,
updated, or committed) you should "cd" to the head of the working
directory you want to tag and type:
cvs tag <tag>
It recursively walks through your working directory tagging the
BASE revisions of all files.
To "tag" the latest revision on the Main branch in the
Repository, you can use the following from anywhere:
(No "cd" is required -- it works directly on the Repository.)
cvs rtag <tag> <module>
2B.8 How do I checkout an old release of a module, directory or file?
Module names and directories are simply ways to name sets of
files. Once the names are determined, there are 6 ways to specify
which revision of a particular file to check out:
1. By tag or symbolic name, via the "-r <tag>" option.
2. By date, via the "-D <date>" option.
3. By branch tag (a type of tag with a magic format), via the
"-r <branch_tag>" option.
4. By date within a branch, via the "-r <branch_tag>:<date>"
option.
5. By an explicit branch revision number, which refers to the
latest revision on the branch. This isn't really an "old"
revision, from the branch's perspective, but from the user's
perspective the branch might have been abandoned in the past.
6. An explicit revision number. Though this works, it is almost
useless for more than one file.
You type:
cvs checkout <option-specified-above> <module>
cd <module>
2B.9 What do I have to remember to do periodically?
You should execute "cvs -n update" fairly often to keep track of
what you and others have changed. It won't change anything -- it
will just give you a report.
Unless you are purposely delaying the inclusion of others' work,
you should execute "update" once in a while and resolve the
conflicts. It is not good to get too far out of sync.
It is assumed that your system administrators have arranged for
editor backup and Unix temp files (#* and .#*) to be deleted after
a few weeks. But you might want to look around for anything else
that is ignored or hidden. Try "cvs -n update -I !" to see all
the ignored files.
If you are the Repository Administrator, see 4B.17.
----------------
-- Section 2C -- Less Common User Tasks
----------------
What I consider a "less common user task" generally involves one or
more of the following commands:
history, import, export, rdiff, release, remove, rtag
**** Questions:
2C.1 Can I create sub-directories in my working directory?
2C.2 How do I add new sub-directories to the Repository?
2C.3 How do I remove a file I don't need?
=2C.4 How do I rename a file?
2C.5 How do I make sure that all the files and directories in my
working directory are really in the Repository?
=2C.6 How do I create a branch?
=2C.7 How do I modify the modules file? How about the other files in
the CVSROOT administrative area?
+2C.8 How do I split a file into pieces, retaining revision histories?
**** Answers:
2C.1 Can I create sub-directories in my working directory?
Yes, but the "update" command will traverse them, wasting a lot
of time. You can't currently ignore directories but if a
directory has no ./CVS administrative directory, nothing will
happen to it during an "update".
On the other hand "release -d" will delete it without warning.
2C.2 How do I add new sub-directories to the Repository?
The "add" command will work on directories. You type:
mkdir <dir>
cvs add <dir>
It will respond:
Add directory /Repos/<dir> to the Repository (y/n) [n] ?
If you type a 'y', you will create both a directory in the
Repository and a ./CVS administrative directory within the local
<dir> directory.
2C.3 How do I remove a file I don't need?
(See the questions in Section 4B on removing files from the
Repository.)
You type:
rm <file>
cvs remove <file>
CVS registers the file for removal. To complete the removal, you
must type:
cvs commit <file>
CVS moves the file to the Attic associated with your working
directory. Each directory in the Repository stores its deleted
files in an Attic sub-directory. A normal "checkout" doesn't
look in the Attic, but if you specify a tag, a date or a
revision, the "checkout" (or "update") command will retrieve
files from the Attic with that tag, date or revision.
=2C.4 How do I rename a file?
CVS does not offer a way to rename a file in a way that CVS can
track later. See Section 4B for more information.
Here is the best way to get the effect of renaming, while
preserving the change log:
1. Copy the RCS (",v") file directly in the Repository.
cp $CVSROOT/<odir>/<ofile>,v $CVSROOT/<ndir>/<nfile>,v
2. Remove the old file using CVS.
By duplicating the file, you will preserve the change
history and the ability to retrieve earlier revisions of the
old file via the "-r <tag/rev>" or "-D <date>" options to
"checkout" and "update".
cd <working-dir>/<odir>
rm <ofile>
cvs remove <ofile>
cvs commit <ofile>
3. Retrieve <newfile> and remove all the Tags from it.
By stripping off all the old Tags, the "checkout -r" and
"update -r" commands won't retrieve revisions Tagged before
the renaming.
cd <working-dir>/<ndir>
cvs update <nfile>
cvs log <nfile> # Save the list of Tags
cvs tag -d <tag1> <nfile>
cvs tag -d <tag2> <nfile>
. . .
This technique can be used to rename files within one directory or
across different directories. You can apply this idea to
directories too, as long as you apply the above to each file and
don't delete the old directory.
Of course, you have to change the build system (e.g. Makefile) in
your <working-dir> to know about the name change.
2C.5 How do I make sure that all the files and directories in my
working directory are really in the Repository?
Normally, you only need to be notified of files you forgot to
"add". A simple "update", or "cvs -n update" (which won't modify
your working directory) will display non-added files preceded by a
'?' indicator. To recover, "add" and "commit" them.
To verify that all your directories are in the Repository, you
have to go look. Though CVS traverses all directories, it
produces no output for directories not backed up by a Repository
directory.
By default many patterns of files are ignored. If you create a
file named "core" or a file ending in ".o", it is usually
ignored. If you really want to see all the files that aren't in
the Repository, you can use a special "ignore" pattern to say
"ignore no files". Try executing: (You may have to quote or
backwhack (i.e. precede by '\') the '!' in your shell.)
cvs -n update -I !
The above command will display not only the normal 'M'odified,
'U'pdate and 'C'onflict indicators on files within the
Repository, but it will also display each file not in the
Repository preceded by a '?' character.
The '-n' option will not allow "update" to alter your working
directory.
=2C.6 How do I create a branch?
Type this in your working directory:
cvs tag -b <branch_tag>
and you will create a branch. No files have real branches in them
yet, but if you move onto the branch by typing:
cvs update -r <branch_tag>
and commit a file in the normal way:
cvs commit <file>
then a branch will be created in the underlying <file>,v file and
the new revision of <file> will appear only on that branch.
See Section 4C, on Branching.
=2C.7 How do I modify the modules file? How about the other files in
the CVSROOT administrative area?
A module named "modules" has been provided in the default modules
file, so you can type:
cvs checkout modules
cd modules
Another module named CVSROOT has been provided in the default
modules file, covering all the administrative files. Type:
cvs checkout CVSROOT
cd CVSROOT
Then you can edit your files, followed by:
cvs commit
If you use the provided template for the "modules" file, both the
CVSROOT and the "modules" module will have the "mkmodules" program
as a "commit helper".
After a file is committed in these modules the "mkmodules"
command will convert all the files CVSROOT directory within the
Repository into a form that is usable by CVS.
+2C.8 How do I split a file into pieces, retaining revision histories?
If you and a coworker find yourselves repeatedly committing the
same file, but never for changes in the same area of the file, you
might want to split the file into two or more pieces. If you are
both changing the same section of code, splitting the file is of
no use. You should talk to each other instead.
If you decide to split the file, here's a suggestion. In many
ways, it is similar to multiple "renamings" as described in
2C.4 above.
Say you want to split <fileA>, which already in the Repository,
into three pieces, <fileA>, <fileB> and <fileC>.
1. Copy the RCS (",v") files directly in the Repository,
creating all the new files.
cp $CVSROOT/<path>/<fileA>,v $CVSROOT/<path>/<fileB>,v
cp $CVSROOT/<path>/<fileA>,v $CVSROOT/<path>/<fileC>,v
cvs update <fileB> <fileC>
2. Then remove all the <tags> from the new files by using:
cvs log <fileB> <fileC> # Save the list of <tag?>
cvs tag -d <tag1> <fileB> <fileC>
cvs tag -d <tag2> <fileB> <fileC>
. . .
3. Edit and commit all three copies of the same file into three
distinct files. This is a hand-editing job, not something
CVS can handle. [From experience, I'd suggest making sure
that only one copy of each line of code exists among the
three files, except for "include" statements, which must be
duplicated. And make sure the code compiles.]
emacs <fileA> <fileB> <fileC>
cvs commit <fileA> <fileB> <fileC>
As in the "rename" case, by duplicating the files, you'll preserve
the change history and the ability to retrieve earlier revisions.
Also, as in the "rename" case, you can apply this idea to
directories too, by changing <path> to <pathA>, <pathB> and
<pathC> in the example.
Of course, you have to change your build system (e.g. Makefile).
----------------
-- Section 2D -- General Questions
----------------
**** Questions:
=2D.1 How do I see what CVS is trying to do?
2D.2 If I work with multiple modules, should I check them all out and
commit them occasionally? Is it OK to leave modules checked out?
2D.3 What is a "sticky" tag? What makes it sticky? How do I loosen it?
2D.4 How do I get an old revision without updating the "sticky tag"?
=2D.5 What operations disregard sticky tags?
=2D.6 Is there a way to avoid reverting my Emacs buffer after
committing a file? Is there a "cvs-mode" for Emacs?
2D.7 How does conflict resolution work? What *really* happens if two
of us change the same file?
2D.8 How can I tell who has a module checked out?
#2D.9 Where did the .#<file>.1.3 file in my working directory come from?
2D.10 What is this "ignore" stuff?
2D.11 Why does .cvsignore not ignore directories?
2D.12 Is it safe to interrupt CVS using Control-C?
2D.13 How do I turn off the "admin" command?
2D.14 How do I turn off the ability to disable history via "cvs -l"?
2D.15 How do I keep certain people from accessing certain directories?
**** Answers:
=2D.1 How do I see what CVS is trying to do?
The '-t' option on the main "cvs" command will display every
external command (mostly RCS commands and file deletions) it
executes. When combined with the '-n' option, which prevents the
execution of any command that might modify a file, you can see
what it will do before you let it fly. The '-t' option will *not*
display every internal action, only calls to external programs.
To see a harmless example, try typing:
cvs -nt update
Some systems offer a "trace" command that will display all system
calls as they happen. This is a *very* low-level interface, but
it can be useful.
The most complete answer is to read the source, compile it
with the '-g' option and execute it under a debugger.
2D.2 If I work with multiple modules, should I check them all out and
commit them occasionally? Is it OK to leave modules checked out?
The simple answers are "Yes."
There is no reason to remove working directories, other than to
save disk space. As long as you have committed the files you
choose to make public, your working directory is just like any
other directory.
CVS doesn't care whether you leave modules checked out or not.
The advantage of leaving them checked out is that you can quickly
visit them to make and commit changes.
2D.3 What is a "sticky" tag? What makes it sticky? How do I loosen it?
When you execute "update -r <tag>", CVS remembers the <tag>. It
has become "sticky" in the sense that until you change it or
remove it, the tag is remembered and used in references to the
file as if you had typed "-r <tag>" on the command line.
It is most useful for a <branch_tag>, which is a sticky tag
indicating what branch you are working on.
A revision number ("-r <rev-number>") or date ("-D <date>") can
also become sticky when they are specified on the command line.
A sticky tag, revision or date remains until you specify another
tag, revision or date the same way. The "update -A" command
moves back to the Main branch, which has the side-effect of
clearing all sticky items on the updated files.
The "checkout" command creates sticky tags, revisions and dates
the same way "update" does.
Also, the '-k' option records a "sticky" keyword option that
is used in further "updates until "update -A" is specified.
2D.4 How do I get an old revision without updating the "sticky tag"?
Use the '-p' option to "pipe" data to standard output. The
command "update -p -r <tag/rev>" sends the selected revision to
your standard output (usually the terminal, unless redirected).
The '-p' affects no disk files, leaving a "sticky tag" unaltered
and avoiding all other side-effects of a normal "update".
If you want to save the result, you can redirect "stdout" to a
file using your shell's redirection capability. In most shells
the following command works:
cvs update -p -r <tag/rev> filename > diskfile
=2D.5 What operations disregard sticky tags?
The functions that routinely disregard sticky tags are:
1. Those that work directly on the Repository or its
administrative files:
admin rtag log status remove history
2. Those that take Tags or revisions as arguments and ignore
everything else: (They also never *set* a sticky tag.)
rdiff import export
3. The "release" command itself ignores sticky tags, but it
calls "cvs -n update" (which *does* pay attention to a
sticky tag) to figure out what inconsistencies exist in
the working directory. If no discrepancies exist between
the files you originally checked out (possibly marked by a
sticky tag) and what is there now, "release -d" will
delete them all.
4. The "tag" command, which works on the revision lying in
the working directory however it got there. That the
revision lying there might happen to have a sticky tag
attached to it is not the "tag" command's concern.
The main function that *does* read and write sticky tags is the
"update" command. You can avoid referring to or changing the
sticky tag by using the '-p' option, which sends files to your
terminal, touching nothing else.
The "checkout" command sets sticky tags when checking out a new
module and it acts like "update" when checking out a module into
an existing directory.
The "diff" and "commit" commands use the sticky tags, unless
overridden on the command line. They do not set sticky tags. (In
the future, "commit" might set a sticky branch tag on a newly
added file.) Note that you can only "commit" to a file checked
out with a sticky tag, if the tag identifies a branch.
There are really two types of sticky tags, one attached to
individual files (in the ./CVS/Entries file) and one attached to
each directory (in the ./CVS/Tag file). They can differ.
The "add" command doesn't pay attention to anything -- it just
registers the desire to add a new file. When a newly added file
is `committed", CVS *should* use the "directory tag" to determine
what branch to commit it to and set the corresponding sticky tag.
Unfortunately, it doesn't work correctly in CVS 1.3. See 4C.8.
=2D.6 Is there a way to avoid reverting my Emacs buffer after
committing a file? Is there a "cvs-mode" for Emacs?
See Section 4F.1
2D.7 How does conflict resolution work? What *really* happens if two
of us change the same file?
While editing files, there is no conflict. You are working on
separate virtual branches of development contained in your working
directories. When one of you decides to commit the file, the
other may not commit the same file until "update" has merged the
two together.
Say you both check out rev 1.2 of <file>. Your coworker commits
revision 1.3. When you try to commit your file, CVS says:
cvs commit: Up-to-date check failed for `<file>'
You must merge your coworker's changes into your working file by
typing:
cvs update <file>
which will produce the output described in 2B.6.
After you resolve any overlaps caused by the merging process, you
may then commit the file.
Yes, the first one who commits can cause the other some work.
Yes, between the time you execute "update" and "commit", someone
else may have committed a later revision of <file>. You will have
to execute "update" again to merge the new work before
committing. Most organizations don't have this problem. If you
do, you might consider splitting the file.
2D.8 How can I tell who has a module checked out?
If you "checkout" module names (not relative pathnames) and you
use the release command, the "history" command will display who
has what checked out. It is advisory only; it can be circumvented
by using the '-l' option on the main "cvs" command.
#2D.9 Where did the .#<file>.1.3 file in my working directory come from?
It was created during an "update" when CVS merged changes from the
Repository into your modified working file.
It serves the same purpose as any "backup" file: saving your bacon
often enough to be worth retaining. It is invaluable in
recovering when things go wrong.
Say Developers A (you) and B check out rev 1.3 of file <file>.
You both make changes -- different changes. B commits first, so
<file>,v in the Repository contains revisions up through 1.4.
At this point, there are 5 (yes, five) versions of the file of
interest to you:
1. Revision 1.3 (What you originally checked out.)
2. Revision 1.4 (What you need from developer B.)
3. Your old working file. (Before the update.)
4. Your new working file. (After the merge caused by "update".)
5. Revision 1.5 (Which you will commit shortly.)
In the case where your working file was not modified, #1 and #3
will be the same, as will #2 and #4. In this degenerate case,
there is no need to create #5. The following assumes that your
working file was modified.
If the merge executed by the "update" caused no overlaps, #4
and #5 will be the same. But you might then make changes before
committing, so the difference between #4 and #5 might be more
than just the correction of overlaps. In general, though, you
don't need #4 after a commit.
But #3 (which is the one saved as ".#<file>.1.3") holds all of
your work, independent of B's work. It could represent a major
effort that you couldn't afford to lose. If you don't save it
somewhere, the merge makes #3 *disappear* under a potential
rat's nest of conflicts caused by overlapping changes.
I have been saved a few times, and others I support have been
saved hundreds of times, by the ability to "diff <original file>
<original file with only my work added>", which can be done in the
example above by the Unix shell command:
cvs update -p -r 1.3 <file> | diff - .#<file>.1.3
The assumption is that the ".#" files will be useful far beyond
the "commit" point, but not forever. You are expected to run
the "normal" Unix cleanup script from "cron", which removes "#*"
and ".#*" files older than a some period chosen by your
sysadmin, usually ranging from 7 to 30 days.
A question was raised about the need for #3 after #5 has been
committed, under the assumption that you won't commit files until
everything is exactly as you like them.
This assumes perfect humans, which violates one of the Cardinal
rules of Software Engineering: Never assume any form of discipline
on the part of the users of software. If restrictions are not
bound into the software, then you, the toolsmith, have to arrange
a recovery path.
In other words, I've seen every possible variety of screwup you
can imagine in #5. There is no way to make assumptions about
what "should" happen. I've seen #5 filled with zeros because of
NFS failures, I've seen emacs core dumps that leave #5 in an
unreasonable state, I've seen a foolish developer uppercase the
whole file (with his "undo" size set low so he couldn't undo it)
and decide that it would be less work to play with the
uppercased file than to blow it away and start over. I've even
seen committed files with conflict markers still in them.
There are all sorts of scenarios where having #3 is incredibly
useful. You can move it back into place and try again.
2D.10 What is this "ignore" stuff?
The "update" and "import" commands use collections of Unix
wildcards to skip over files matching any of those patterns.
You may add to the built-in ignore list by adding wildcards to
the following places: (They are read in this order.)
1. In a file named "cvsignore" in $CVSROOT/CVSROOT.
A Repository Administrator uses this to add site-specific
files and patterns to the built-in ignore list.
2. In a file named ".cvsignore" in your home directory.
For user-specific files. For example, if you use "__" as
your default junk file prefix, you can put "__*" in your
.cvsignore file.
People who play around in the X tree might want to put
"Makefile" in their ignore list, since they are all
generated and usually don't end up in the Repository.
3. In the CVSIGNORE environment variable.
For session-specific files.
4. Via the '-I' option on "import" or "update" commands.
For this-command-only files.
5. In a file named ".cvsignore" within each directory.
The contents of a ".cvsignore" file in each directory is
temporarily added to the ignore list. This way you can ignore
files that are peculiar to that directory, such as executables
and other files without known suffix patterns.
In any of the 5 places listed above, a single '!' character nulls
out the ignore list. A Repository administrator can use this to
override, rather than enhance, the built-in ignore list. A user
can choose to override the system-wide ignore list. For example,
if you place "! *.o *.a" in your .cvsignore file, only *.o *.a
files, plus any files a local-directory .cvsignore file, are
ignored.
2D.11 Why does .cvsignore not ignore directories?
Ignore lists are intended to be per-directory wildcards matching
various patterns. They are matched against file names, not
directory names or relative paths ('/' is an invalid character in
an ignore list). I suppose it could be extended, but as it
stands, it only works on files.
This might change in the future.
2D.12 Is it safe to interrupt CVS using Control-C?
It depends on what you mean by "safe". ("Ah," said Arthur,
"this is obviously some strange usage of the word *safe* that I
wasn't previously aware of." -- Hitchhiker's Guide to the Galaxy)
You won't hurt the underlying RCS files and if you are executing a
command that only *reads* data, you will have no cleanup to do.
But you may have to hit Control-C repeatedly to stop it. CVS uses
the Unix "system" routine which blocks signals in the CVS parent
process. A single Control-C during "system" will only halt the
child process, usually some form of RCS command.
If you don't hit another Control-C while the CVS process has
control, it is likely to continue onto the next task assuming that
the earlier one did its job. It is not enough to hit two
Control-C's. You might simply kill two child processes and not
interrupt CVS at all. Depending on the speed of your processor,
your terminal and your fingers, you might have to hit dozens of
Control-C's to stop the damn thing.
Executing a CVS command, such as "commit" or "tag" that writes
to the files is a different matter.
Since CVS is not a full-fledged database, with what database
people call "commit points", merely stopping the process will
not place you back in the starting blocks. CVS has no concept of
an "atomic" transaction or of "backtracking", which means that
a command can be half-executed.
First, you will usually leave lock files that you have to go clean
up in the Repository.
Example1:
If you interrupt a multi-file "commit" in the middle of
an RCS checkin, RCS will leave the file either fully
checked-in or in its original state. But CVS might have
been half-way through the list of files to commit. The
directory or module will be inconsistent.
To recover, you must remove the lock files, then decide
whether you want to back out or finish the job.
To back out, you'll have to apply the "admin -o"
command, very carefully, to remove the newly committed
revisions. This is usually a bad idea, but is
occasionally necessary.
To finish, you can simply retype the same commit command.
CVS will figure out what files are still modified and
commit them. It helps that RCS doesn't leave a file in an
intermediate state.
Example2:
If you interrupt a multi-file "tag" command, you have a
problem similar, but not equivalent, to interrupting a
"commit". The RCS file will still be consistent, but
unlike "commit", which only *adds* to the RCS file, "tag"
can *move* a tag and it doesn't keep a history of what
revision a tag used to be attached to.
Normally, you have little choice but to re-execute the
command and allow it to tag everything consistently.
You might be able to recover by applying a raw "rcs -n" to
the Repository, or by using the equivalent: "cvs admin".
Halting a new "checkout" should cause no harm. If you don't want
it, "release" (or rm -rf) it. If you do want it, re-execute the
command.
Halting "update" half-way will give you some strange collection
of files and revisions. You'll have to examine the output from
the command and take a look at each file that was modified. Good
Luck.
2D.13 How do I turn off the "admin" command?
In the current revision, you'd have to edit the source code.
2D.14 How do I turn off the ability to disable history via "cvs -l"?
In the current revision, you'd have to edit the source code.
2D.15 How do I keep certain people from accessing certain directories?
If you don't try to run CVS set[ug]id, you can use Unix groups and
permissions to limit access to the Repository.
If you only want to limit "commit" commands, you can write a
program to put in the "commitinfo" file. In the "contrib"
directory, there is a script called "cvs_acls.pl" that implements
a form of access control.
========================================
== Section 3 ==== Commands ====
========================================
This section contains questions that are easily recognized to be about a
single command, usually of the form: "Why does the 'xyz' command do this?"
Questions about "missing" features and side-effects not attributable to a
particular command are in Section 2D, "General Questions".
I won't provide patches here that are longer than a few lines. Patches
referred to in this section are available in the FTP archive described
toward the beginning of this document.
----------------
-- Section 3A -- "add", "ad", "new"
----------------
**** Questions:
3A.1 What is "add" for?
3A.2 How do I add a new file to the branch I'm working on?
3A.3 Why did my newly added file end up in the Attic?
3A.4 How do I put a new file on the Main Branch and branch off from
there onto my default branch?
**** Answers:
3A.1 What is "add" for?
To add a new directory to the Repository or to register the
desire to add a new file to the Repository.
The directory is created immediately, after verification, while
the desire to add the file is recorded in the local ./CVS
administrative directory. To really add the file to the
Repository, you must then "commit" it.
3A.2 How do I add a new file to the branch I'm working on?
See 4C.8
3A.3 Why did my newly added file end up in the Attic?
Your new file is placed in the Attic if it is added onto a side
branch without ever showing up on the trunk.
If the file were in the main Repository area, it would show up
when the Main branch is checked out. You didn't commit it onto
the Main branch -- only onto the side branch.
3A.4 How do I put a new file on the Main Branch and branch off from
there onto my default branch?
See 4C.8
----------------
-- Section 3B -- "admin", "adm", "rcs"
----------------
**** Questions:
3B.1 What is "admin" for?
3B.2 Wow! Isn't that dangerous?
=3B.3 What would I normally use "admin" for?
=3B.4 What should I avoid when using "admin"?
-3B.5 How do I restrict the "admin" command? The -i flag in the modules
file can restrict commits. What's the equivalent for "admin"?
+3B.6 I backed out a revision with "admin -o" and committed a
replacement. Why doesn't "update" retrieve the new revision?
**** Answers:
3B.1 What is "admin" for?
To provide direct access to the underlying "rcs" command, which
is not documented in this FAQ
3B.2 Wow! Isn't that dangerous?
Yes.
Though you can't hurt the internal structure of an RCS file using
its own "rcs" command, you *can* change the underlying RCS
files using "admin" in ways that CVS can't handle.
If you feel the need to use "admin", create some test files
with the RCS "ci" command and experiment on them with "rcs"
before blasting any CVS files.
=3B.3 What would I normally use "admin" for?
Normally, you wouldn't use admin at all. In unusual
circumstances, experts can use it to set up or restore the
internal RCS state that CVS requires.
You can also use the '-o' (for "outdate") option to remove
revisions you don't care about. This has its own problems, such
as leaving dangling Tags and confusing the "update" command.
=3B.4 What should I avoid when using "admin"?
Never use "admin" to alter branches (using the '-b' option), which
CVS takes very seriously. If you change the default branch, CVS
will not work as expected. If you create new branches without
using the "tag -b" command, you may not be able to treat them as
CVS branches.
Don't try to use the '-l' option, which will lock RCS files.
See 4D.7 for a cautionary scenario.
The "admin -o <file>" allows you to delete revisions, usually a
bad idea. You should commit a correction rather than back out a
revision. Outdating a revision is prone to all sorts of problems:
1. Discarding data is always a bad idea. Unless something in the
revision you just committed is a threat to your job or your
life, (like naming a function "<boss's name>_is_a_dweeb", or
including the combination to the local Mafioso's safe in a C
comment), just leave it there. No one cares about simple
mistakes -- just commit a corrected revision.
2. The time travel paradoxes you can cause by changing history
are not worth the trouble. Even if CVS can't interfere with
your parents' introduction, it *can* log commits in at least
two ways (history and loginfo). The reports now lie -- the
revision referred to in the logs no longer exists.
3. If you used "import" to place <file> into CVS, outdating all
the revisions on the Main branch back to and including revision
1.2 (or worse, 1.1), will produce an invalid CVS file.
If the <file>,v file only contains revision 1.1 (and the
connected branch revision 1.1.1.1), then the default branch
must be set to the Vendor branch as it was when you first
imported the file. Outdating back through 1.2 doesn't restore
the branch setting. Despite the above admonition against it,
"admin -b" is the only way to recover:
cvs admin -b1.1.1 <file>
4. Although you can't outdate a physical (RCS) branch point
without removing the whole branch, you *can* outdate a revision
referred to by a magic branch tag. If you do so, you will
invalidate the branch.
5. If you "outdate" a tagged revision, you will invalidate all
uses of the <tag>, not just the one on <file>. A tag is
supposed to be attached to a consistent set of files, usually a
set built as a unit. By discarding one of the files in the
set, you have destroyed the utility of the <tag>. And it
leaves a dangling tag, which points to nothing.
6. And even worse, if you commit a revision already tagged, you
will alter what the <tag> pointed to without using the "tag"
command. For example, if revision 1.3 has <tag> attached to it
and you "outdate" the 1.3 revision, <tag> will point to a
nonexistent revision. Although this is annoying, it is nowhere
near as much trouble as the problem that will occur when you
commit to this file again, recreating revision 1.3. The old
tag will point to the new revision, a file that was not in
existence when the <tag> was applied. And the discrepancy is
nearly undetectable.
If you don't understand the above, you should not use the admin
command at all.
-3B.5 How do I restrict the "admin" command? The -i flag in the modules
file can restrict commits. What's the equivalent for "admin"?
At this writing, to disable the "admin" command, you will have
to change the program source code, recompile and reinstall.
+3B.6 I backed out a revision with "admin -o" and committed a
replacement. Why doesn't "update" retrieve the new revision?
CVS is confused because the revision in the ./CVS/Entries file
matches the latest revision in the Repository *and* the timestamp
in the ./CVS/Entries file matches your working file. CVS believes
that your file is "up-to-date" and doesn't need to be updated.
You can cause CVS to notice the change by "touch"ing the file.
Unfortunately what CVS will tell you is that you have a "Modified"
file. If you then "commit" the file, you will bypass the
normal CVS check for "up-to-date" and will probably commit the
revision that was originally removed by "admin -o".
Changing a file without changing the revision number confuses CVS
no matter whether you did it by replacing the revision (using
"admin -o" and "commit" or raw RCS commands) or by applying an
editor directly to a Repository (",v") file. Don't do it unless
you are absolutely certain no one has the latest revision of the
file checked out.
The best solution to this is to institute a program of deterrent
flogging of abusers of "admin -o".
The "admin" command has other problems." See 3B.4 above.
----------------
-- Section 3C -- "checkout", "co", "get"
----------------
**** Questions:
3C.1 What is "checkout" for?
3C.2 What is the "module" that "checkout" takes on the command line?
3C.3 Isn't a CVS "checkout" just a bunch of RCS checkouts?
3C.4 What's the difference between "update" and "checkout"?
3C.5 Why can't I check out a file from within my working directory?
3C.6 How do I avoid dealing with those long relative pathnames?
3C.7 Can I move a checked-out directory? Does CVS remember where it
was checked out?
#3C.8 How can I lock files on checkout the way RCS does?
+3C.9 What is "checkout -s"? How is it different from "checkout -c"?
**** Answers:
3C.1 What is "checkout" for?
To acquire a copy of a module (or set of files) to work on.
All work on files controlled by CVS starts with a "checkout".
3C.2 What is the "module" that "checkout" takes on the command line?
It is a name for a directory or a collection of files in the
Repository. It provides a compact name space and the ability to
execute before and after helper functions based on definitions in
the modules file.
See 1D.11.
3C.3 Isn't a CVS "checkout" just a bunch of RCS checkouts?
Like much of CVS, a similar RCS concept is used to support a CVS
function. But a CVS checkout is *not* the same as an RCS
checkout.
Differences include:
1. CVS does not lock the files. Others may access them at the
same time.
2. CVS works best when you provide a name for a collection of
files (a module or a directory) rather than an explicit list of
files to work on.
3. CVS remembers what revisions you checked out and what branch
you are on, simplifying later commands.
3C.4 What's the difference between "update" and "checkout"?
The "checkout" and "update" differ in the following ways:
1. The "checkout" command always creates a directory, moves into
it, then becomes equivalent to "update -d".
2. The "update" does not create directories unless you add the
'-d' option.
3. "Update" is intended to be executed within a working directory
created by "checkout". It doesn't take a "module" or
"directory" argument, but figures out what Repository files to
look at by reading the ./CVS administrative directory.
4. The two commands generate completely different types of records
in the "history" file.
The two commands are equivalent in nearly all other respects.
3C.5 Why can't I check out a file from within my working directory?
You normally check out a module or directory, not a file. And you
normally do it only once at the beginning of a project.
After the initial "checkout", you can use the "update" command
to retrieve any file you want within the checked-out directory.
There is no need for further "checkout" commands.
If you want to retrieve another module or directory to work on,
you must provide names for both where to find it in the Repository
and where to put it on disk. The "modules" file and your
current directory supply two pieces of naming information. While
inside a checked-out working directory, the CVS administrative
information provides most of the rest.
You should be careful not to confuse CVS with RCS and use
"checkout" in the RCS sense. An RCS "checkout" (which is
performed by the RCS "co" command) is closer to a "cvs update"
than to a "cvs checkout".
3C.6 How do I avoid dealing with those long relative pathnames?
This question has also been phrased:
How do I avoid all those layers of directories on checkout?
or
Why do I have to go to the top of my working directory and
checkout some long pathname to get a file or two?
This type of question occurs only among groups of people who
decide not to use "modules". The answer is to use "module".
When you hand the "checkout" command a relative pathname, rather
than a module name, all directories in the path are created,
maintaining the same directory hierarchy as in the Repository.
The same kind of environment results if you specify a "module"
that is really an alias expanding into a list of relative
pathnames rather than a list of module names.
If you use "module" names, "checkout" creates a single
directory by the name of the module in your current directory.
This "module" directory becomes your working directory.
The "module" concept combines the ability to "name" a collection
of files with the ability to structure the Repository so that
consistent sets of files are checked out together. It is the
responsibility of the Repository Administrators to set up a
modules file that describes the software within the Repository.
I consider it unfortunate that CVS sprouted the ability to check
out relative pathnames without more extensive and flexible
support for "modules."
3C.7 Can I move a checked-out directory? Does CVS remember where it
was checked out?
Yes and Yes.
The ./CVS/Repository file in each working directory contains a
pathname pointing to the matching directory within the
Repository. The pathname is either absolute or relative to
$CVSROOT, depending on how you configured CVS.
When you move a checked-out directory, the CVS administrative
files will move along with it. As long as you don't move the
Repository itself, or alter your $CVSROOT variable, the moved
directory will continue to be usable.
CVS remembers where you checked out the directory in the
"history" file, which can be edited, or even ignored if you
don't use the "working directory" information displayed by the
"history" command.
#3C.8 How can I lock files on checkout the way RCS does?
Think about why you want that ability. RCS locking is there to
keep people from breaking individual files. CVS does the same
task a different way. If you are only looking for the consistency
aspect, then you should just forget about locking. For normal
development, there is no need for CVS to lock anything.
If you want to restrict access to parts of the Repository, see
the question in Section 4B on "Limiting Access".
+3C.9 What is "checkout -s"? How is it different from "checkout -c"?
The '-c' and '-s' options to "checkout" both cause the modules
file to appear on standard output, but formatted differently.
"checkout -c" lists the modules file alphabetized by the module
name. It also prints all data (including options like '-a' and
"-o <prog>") specified in the modules file.
"checkout -s" lists the modules file sorted by "status" field,
then by module name. The status field was intended to allow you
to mark modules with strings of your choice to get a quick sorted
report based on the data you chose to put in the status fields. I
have used it for priority ("Showstopper", etc as tied into a bug
database), for porting status ("Ported", "Compiled", etc. when
porting a large collection of modules), for "assignee" (the person
responsible for maintenance), and for "test suite" (which
automatic test procedure to run for a particular module).
[[CVS 1.3 fails to handle all the flags you can put into the
modules file. The '-l' switch in particular causes "checkout -c"
to dump core on some systems.]]
----------------
-- Section 3D -- "commit", "ci", "com"
----------------
**** Questions:
3D.1 What is "commit" for?
=3D.2 If I edit ten files, do I have to type "commit" ten times?
3D.3 Explain: cvs commit: Up-to-date check failed for `<file>'
3D.4 What happens if two people try to "commit" conflicting changes?
3D.5 I committed something and I don't like it. How do I remove it?
=3D.6 Explain: cvs commit: sticky tag `V3' for file `X' is not a branch
=3D.7 Why does "commit -r <branch_tag>" put new files in the attic?
+3D.8 Why does "commit -r <rev>" ignore <rev> on an added file?
**** Answers:
3D.1 What is "commit" for?
To store new revisions in the Repository, making them visible
to other users.
=3D.2 If I edit ten files, do I have to type "commit" ten times?
No. The "commit" command will take multiple filenames on the
command line and commit them all with the same log message.
If the file is unchanged, CVS will skip it.
Like all CVS commands, "commit" will work on the whole directory
by default. Just type "cvs commit" to tell CVS to commit all
modified files (i.e. the files that "update" would display
preceded by 'M') in the current directory and in all
sub-directories.
3D.3 Explain: cvs commit: Up-to-date check failed for `<file>'
You may not "commit" a file if your BASE revision (i.e. the
revision you last checked out, committed or retrieved via
"update") doesn't match the HEAD revision (i.e the latest revision
on your branch, usually the Main Branch).
In other words, someone committed a revision since you last
executed "checkout", "update" or "commit". You must now execute
"update" to merge the other person's changes into your working
file before "commit" will work. You are thus protected (somewhat)
from a common form of race condition in source control systems,
where a second checkin of minor changes from the same base file
obliterates the changes made in the first.
Normally, the "update" command's auto-merge should be followed
by another round of building and testing before the "commit".
3D.4 What happens if two people try to "commit" conflicting changes?
Conflicts can occur only when two developers check out the same
revision of the same file and make changes. The first developer
to commit the file has no chance of seeing the conflict. Only the
second developer runs into it, usually when faced with the
"Up-to-date" error explained in the previous question.
There are two types of conflicts:
1. When two developers make changes to the same section of code,
the auto-merge caused by "update" will print a 'C' on your
terminal and leave "overlap" markers in the file.
You are expected to examine and clean them up before committing
the file. (That may be obvious to *some* of you, but . . .)
2. A more difficult problem arises when two developers change
different sections of code, but make calls to, or somehow
depend on, the old version of each other's code.
The auto-merge does the "right" thing, if you view the file
as a series of text lines. But as a program, the two
developers have created a problem for themselves.
This is no different from making cross-referential changes in
*separate* files. CVS can't help you. In a perfect world, you
would each refer to the specification and resolve it
independently. In the real world you have to talk/argue, read
code, test and debug until the combined changes work again.
Welcome to simultaneous development.
3D.5 I committed something and I don't like it. How do I remove it?
Though you *can* use the "admin -o" (synonym: "rcs -o") command to
delete revisions, unless the file you committed is so embarrassing
that the need to eradicate it overrides the need for being
careful, you should just grab an old version of the file ("update
-p -r <previous-rev>" might help here) and commit it on top of the
offending revision.
See Section 3B on "admin".
=3D.6 Explain: cvs commit: sticky tag `V3' for file `X' is not a branch
The message implies two things:
1. You created your working directory by using "checkout -r
V3", or you recently executed "update -r V3".
2. The tag named V3 is not a branch tag.
CVS remembers any "-r <tag/rev>" arguments handed to the
"checkout" or "update" commands. This is the "sticky" part. The
<tag/rev> is recorded as the CVS working branch, which is the
branch to which "commit" will add a new revision.
Branch tags are created when you use the -b switch on the "tag" or
"rtag" commands. Branch tags are magic tags that don't create a
physical branch, but merely mark the revision to branch from when
the branch is needed. The first commit to a magic branch creates
a physical branch in the RCS files.
You can commit onto the end of the Main Trunk, if you have no
sticky tag at all, or onto the end of a branch, if you have a
sticky branch tag. But you can't commit a file that has a sticky
tag not pointing to a branch. CVS assumes a sticky Tag or
Revision that does not refer to a branch is attached to the middle
of a series of revisions. You can't squeeze a new revision
between two others. Sticky dates also block commits since they
never refer to a branch.
Scenario1:
If you don't want a branch and were just looking at an old
revision, then you can move back to the Main Branch by typing:
cvs update -A {optional files, default is whole directory}
Scenario2:
If you really wanted to be on a branch and made an earlier
mistake by tagging your branch point with a non-branch tag,
you can recover by adding a new branch tag to the old
non-branch tag:
cvs rtag -b -r <oldtag> <newtag> <module>
(It was not a big mistake. Branch-point tags can be useful.
But the <newtag> must have a different name.)
If you don't know the <module> name or don't use "modules",
you can also use "tag" this way:
cvs update -r <oldtag>
cvs tag -b <newtag> .
Then, to put your working directory onto the branch, you type:
cvs update -r <newtag>
You can't delete <oldtag> before adding <newtag>, and I would
not advise deleting the <oldtag> at all, because it is useful
in referring to the branch point. If you must, you can delete
the non-branch tag by:
cvs rtag -d <oldtag> <module>
or
cvs tag -d <oldtag> .
Scenario3:
If you made the same mistake as in Scenario2, but really want
<oldtag> to be the name of your branch, you can execute a
slightly different series of commands to rename it and move
your working directory onto the branch:
cvs rtag -r <oldtag> <branch_point_tag> <module>
cvs rtag -d <oldtag> <module>
cvs rtag -b -r <branch_point_tag> <oldtag> <module>
Then, if you really must, delete the <branch_point_tag>:
cvs rtag -d <branch_point_tag> <module>
Note: The unwieldy mixture of "tag" and "rtag" is mostly
because you can't specify a revision (-r <tag>) to the
"tag" command.
See 4C.3 for more details.
=3D.7 Why does "commit -r <branch_tag>" put new files in the attic?
This was a design choice. The Attic is a way to keep track of
files that are no longer on the Main Branch, or ones that were
*never* on the Main Branch.
If the file doesn't already exist on the Main branch, committing
it directly to the BRANCH will stuff it into the Attic. Such
files are skipped over when checking out the Main Branch because
the file isn't on that branch.
If it didn't go into the Attic, you would be committing the new
file to the Main branch in addition to the Branch you are working
on. This is an undesirable side-effect.
The file can be retrieved by using the "-r <branch_tag>" option on
a "checkout" or "update" command.
See Section 4C, on Branching, for many more details.
+3D.8 Why does "commit -r <rev>" ignore <rev> on an added file?
The sequence
cvs add <file>
cvs commit -r <rev> <file>
does not commit the new file <file> with revision <rev> as you
might expect. For newly added files (for which "update" would
display an 'A') the '-r' option is assumed to be a branch tag. If
<rev> is numeric, it is ignored. This might or might not be
changed in future revisions of CVS, but for now, the following
commands will allow you to set the revision of the file: (with
some restrictions)
cvs add <file>
cvs commit <file>
cvs commit -r <rev> <file>
The first commit causes CVS to look for the highest main branch
major number in all files in the directory. Normally it is '1',
but if you have a file of revision 3.27 in your directory, CVS
will find the '3' and create revision 3.1 for the first rev of
<file>. Normally, the first revision is 1.1.
As long as <rev> is higher than the initial (calculated as in the
above) revision, the second commit will work as expected and force
a second commit even if the file hasn't changed, setting the file
revision to <rev>.
----------------
-- Section 3E -- "diff", "di", "dif"
----------------
**** Questions:
3E.1 What is "diff" for?
=3E.2 Why did "diff" display nothing when I know there are later
committed revisions in the Repository?
#3E.3 How do I display what changed in the Repository since I last
executed "checkout", "update" or "commit"?
=3E.4 How do I display the difference between my working file and what
I checked in last Thursday?
=3E.5 Why can't I pass the --unified option to "diff"?
**** Answers:
3E.1 What is "diff" for?
To display the difference between your working file and a
committed revision:
cvs diff -r <tag/rev> <file>
or between two committed revisions:
cvs diff -r <tag1/rev1> -r <tag2/rev2> <file>
Without explicit file names, it "diffs" the whole directory.
Without explicit revision numbers, it "diffs" your working file
against the BASE revision, which is the one last checked out,
updated or committed.
In the examples above, "-D <date>" may be substituted wherever
"-r <tag/rev>" appears. The revision a <date> refers to is the
revision that existed on that date.
=3E.2 Why did "diff" display nothing when I know there are later
committed revisions in the Repository?
By default, "diff" displays the difference between your working
file and the BASE revision. If you haven't made any changes to
the file since your last "checkout", "update" or "commit" there is
no difference to display.
To display the difference between your working file and the latest
revision committed to your current branch, type:
cvs diff -r HEAD <file>
#3E.3 How do I display what changed in the Repository since I last
executed "checkout", "update" or "commit"?
A special tag (interpreted by CVS -- it does not appear in the Tag
list) named "BASE" always refers to the revision you last checked
out, updated or committed. Another special tag named "HEAD"
always refers to the latest revision on your working branch.
To compare BASE and HEAD, you type:
cvs diff -r BASE -r HEAD <file>
=3E.4 How do I display the difference between my working file and what
I checked in last Thursday?
cvs diff -D "last Thursday" <file>
where "last Thursday" is a date string. To be more precise, the
argument to the '-D' option is a timestamp. Many formats are
accepted. See the man page under "-D date_spec" for details.
=3E.5 Why can't I pass the --unified option to "diff"?
There are a few reasons:
1. CVS passes through only arguments it knows about, because a few
arguments are captured and interpreted.
2. CVS only parses single character '-X' arguments, not the FSF
long options.
3. If you didn't configure RCS and CVS to use the GNU version of
diff, long options wouldn't work even if future versions of CVS
acquire the ability to pass them through.
Most of the long options have equivalent single-character options,
which do work. The "--unified" option is equivalent to '-u' in
revisions of GNU diff since 1.15.
----------------
-- Section 3F -- "export", "exp", "ex"
----------------
**** Questions:
3F.1 What is "export" for?
=3F.2 Why does it remove the RCS keywords so I can't use the "ident"
command on the source files?
=3F.3 Can I override the '-kv' flag CVS passes to RCS?
=3F.4 Why the hell not?
3F.5 Why does "export -D" check out every file in the Attic?
**** Answers:
3F.1 What is "export" for?
"export" checks out a copy of a module in a form intended for
export outside the CVS environment. The "export" command produces
the same directory and file structure as the "checkout" command,
but it doesn't create "CVS" sub-directories and it removes all the
RCS keywords from the files.
=3F.2 Why does it remove the RCS keywords so I can't use the "ident"
command on the source files?
It removes the RCS keywords, so that if the recipient of the
exported sources checks them into another set of RCS files (with
or without CVS), and then makes modifications through RCS or CVS
commands, the revision numbers that they had when you exported
them will be preserved. (That ident no longer works is just an
unfortunate side effect.)
The theory is that you are exporting the sources to someone else
who will make independent changes, and at some point you or they
will want to know what revisions from your Repository they started
with (probably to merge changes, or to try to decide whether to
merge changes).
A better way to handle this situation would be to give them their
own branch of your Repository. They would need to remember to
checkin the exported sources with RCS IDs intact (ci -k) so that
their changes would get revision numbers from the branch, rather
than starting at 1.1 again. Perhaps a future version of CVS will
provide a way to export sources this way.
Contributed by Dan Franklin
=3F.3 Can I override the '-kv' flag CVS passes to RCS?
Not in CVS 1.3. Maybe later.
=3F.4 Why the hell not?
Export is intended for a specific purpose -- to remove all trace
of revision control on the way *out* of CVS. Maybe in the future
CVS will allow the -kv default to be overridden.
3F.5 Why does "export -D" check out every file in the Attic?
See the explanation of the same problem with "update -D"
contained in section 5B.
----------------
-- Section 3G -- "history", "hi", "his"
----------------
**** Questions:
3G.1 What is "history" for?
3G.2 Of what use is it?
3G.3 What is this, Big Brother?
3G.4 I deleted my working directory and "history" still says I have
it checked out. How do I fix it?
3G.5 So I *can* edit the History file?
3G.6 Why does the history file grow so quickly?
3G.7 What is the difference between "cvs history -r <tag/rev>" and
"cvs history -t <tag>"?
3G.8 Why does "cvs history -c -t <tag>" fail to print anything?
3G.9 "cvs history -a -o" only printed one line for each checked-out
module. Shouldn't it print all the directories where the
modules are checked out?
=3G.10 I can't figure out "history", can you give me concrete examples?
**** Answers:
3G.1 What is "history" for?
To provide information difficult or impossible to extract out of
the RCS files, such as a "tag" history or a summary of module
activities.
3G.2 Of what use is it?
I have found it useful in a number of ways, including:
1. Providing a list of files changed since
- A tagged release.
- Yesterday, last Thursday, or a specific date.
- Someone changed a specific file.
2. Providing a list of special events:
- Files added or removed since one of the above events.
- Merge failures since one of the above events. (Where did the
conflicts occur?)
- Has anyone (and who) grabbed the revision of this file I
committed last week, or are they still working blind?
3. Telling me how often a file/directory/module has been changed.
4. Dumping a summary of work done on a particular module,
including who last worked on it and what changed.
5. Displaying the checked-out modules and where they are being
worked on.
6. To tell me what users "joe" and "malcolm" have done this week.
3G.3 What is this, Big Brother?
War is Peace.
Freedom is Slavery.
Ignorance is Strength.
Normally manager types and those with the power to play Big
Brother don't care about this information. The Software Engineer
responsible for integration usually wants to know who is working
on what and what changed. Use your imagination.
3G.4 I deleted my working directory and "history" still says I have
it checked out. How do I fix it?
In later versions of CVS, you can use the '-f' option which
forcibly adds a "release" record to the history file. If your
version of "release" doesn't have the '-f' option, you have
to edit the $CVSROOT/CVSROOT/history file.
You can remove the last 'O' line in the history file referring
to the module in question or add an 'F' record.
3G.5 So I *can* edit the History file?
Yes, but if you are using history at all, you should take a little
care not to lose information. I normally use Emacs on the file,
since it can detect that a file has changed out from under it.
You could also copy and zero out the history file, edit the copy
and append any new records to the edited copy before replacing it.
3G.6 Why does the history file grow so quickly?
It stores 'U' records, which come in handy sometimes when you
are tracking whether people have updated each other's code
before testing. There should (and probably will sometime) be a
way to choose what kinds of events go into the history file.
The contributed "cln_hist.pl" script will remove all the 'U'
records, plus matching pairs of 'O' and 'F' records during
your normal clean up of the history file.
3G.7 What is the difference between "cvs history -r <tag/rev>" and
"cvs history -t <tag>"?
The '-t' option looks for a Tag record stored by "rtag" in the
history file and limits the search to dates after the last <tag>
of the given name was added.
The '-r' option was intended to search all files looking for the
<tag> in the RCS files. It takes forever and needs to be
rewritten.
3G.8 Why does "cvs history -c -t <tag>" fail to print anything?
You have been using "tag" instead of "rtag". The "tag" command
currently doesn't store a history record. This is another remnant
of CVS's earlier firm belief in "modules".
3G.9 "cvs history -a -o" only printed one line for each checked-out
module. Shouldn't it print all the directories where the
modules are checked out?
Not as designed.
Command Question it is supposed to answer.
---------------- ------------------------------------------
cvs history -o What modules do I have checked out?
cvs history -a -o <same for all users>
cvs history -o -w What working directories have I created
and what modules are in them?
cvs history -a -o -w <same for every user>
The -o option chooses the "checked out modules" report, which is
the default history report.
=3G.10 I can't figure out "history", can you give me concrete examples?
Default output selects records only for the user who executes the
"history" command. To see records for other users, add one or
more "-u user" options or the '-a' option to select *all* users.
To list (for the selected users): Type "cvs history" and:
* Checked out modules: -o (the default)
* Files added since creation: -x A
* Modified files since creation: -c
* Modified files since last Friday: -c -D 'last Friday'
* Modified files since TAG was added: -c -t <tag>
* Modified files since TAG on files: -c -r <tag>
* Last modifier of file/Repository X? -c -l -[fp] X
* Modified files since string "str": -c -b str
* Tag history: (Actually "rtag".) -T
* History of file/Repository/module X: -[fpn] X
* Module report on "module": -m module
----------------
-- Section 3H -- "import", "im", "imp"
----------------
**** Questions:
=3H.1 What is "import" for?
=3H.2 How am I supposed to use "import"?
=3H.3 Why does import put files on a branch? Why can't you put it on
the Main Trunk and let me work on a branch?
3H.4 Is there any way to import binary files?
=3H.5 Why does "import" corrupt some binary files?
3H.6 How do I keep "import" from expanding all the $\Revision$ strings
to be 1.1.1.1?
#3H.7 I imported some files for the Yarg compiler that compiles files
with a suffix of ".yarg" and whose comment prefix is "YARG> ".
When I check them out, they will no longer compile because they
have this junk in them. Why?
3H.8 How do I make "import" save the timestamps on the original files?
3H.9 Why didn't "import" ignore the directories I told it to?
3H.10 Why can't I "import" 3 releases on different branches?
3H.11 What do I do if the Vendor adds or deletes files between releases?
3H.12 What about if the Vendor changes the names of files or
directories, or rearranges the whole structure between releases?
3H.13 I thought "import" was for Vendor releases, why would I use it
for code of my own? Do I have to use import?
=3H.14 How do I import a large Vendor release?
+3H.15 Explain: ERROR: cannot create link to <file>: Permission denied
**** Answers:
=3H.1 What is "import" for?
The "import" command is a fast way to insert a whole tree of files
into CVS.
The first "import" to a particular file within the Repository
creates an RCS file with a single revision on the "Vendor branch."
Subsequent "import"s of the same file within the Repository append
a new revision onto the Vendor branch. It does not, as some seem
to believe, create a new branch for each "import". All "imports"
are appended to the single Vendor branch.
If the file hasn't changed, no new revision is created -- the new
"Release-Tag" is added to the previous revision.
After the import is finished, files you have not changed locally
are considered to have changed in the "Main line of development".
Files you *have* changed locally must have the new Vendor code
merged into them before they are visible on the "Main line".
See 4C.6 and 4C.15
=3H.2 How am I supposed to use "import"?
Create a source directory containing only the files you want to
import. Make sure you clean up any cruft left over from previous
builds or editing. You want to make sure that the directory
contains only what you want to call "source" from which everything
else is built.
"cd" into your source directory and type:
cvs import -m "Message" <repos> <Vendor-Tag> <Release-Tag>
where <repos> is a relative directory pathname within the
Repository.
For example, if the FSF, CVS, Make and I are still active in the
year 2015, I'll import version 89.53 of GNU make this way:
cvs import -m "GNUmake V89.53" gnu/make GNU GNUMAKE_89_53
See 3H.14 for more details.
=3H.3 Why does import put files on a branch? Why can't you put it on
the Main Trunk and let me work on a branch?
Design choice. If you don't like the Vendor branch, you can use
the RCS "ci" command to generate all the RCS (",v") files and move
them into the Repository directly.
Note that the CVS "Main Branch" and the RCS Main Trunk are not the
same. Placing files on the Vendor Branch doesn't keep you from
creating a development branch to work on.
See Section 4C, on Branching.
3H.4 Is there any way to import binary files?
See 4D.1 on Binary files.
=3H.5 Why does "import" corrupt some binary files?
The RCS "co" command, when it is invoked by a CVS "checkout" or
"update" (or after a "commit") command, searches for and expands a
list of keywords within the file. They are documented in the RCS
"co" man page. Strings such as "$\Id$" (or "$\Id:"), or
"$\Revision$" (or "$\Revision:") are altered to the include the
indicated information.
[[Note: The keywords should appear in the text without the '\'
character I have inserted to *avoid* expansion here. The only
real RCS keywords in this document are at the top of the file,
where I store the Revision and Date.]]
If RCS keyword strings show up in a binary file, they will be
altered unless you set the '-ko' option on the RCS files to tell
RCS to keep the original keyword values and not to expand new
ones. After "import", you can set the '-ko' option this way:
cvs admin -ko <file>
rm <file>
cvs update <file>
See 4D.1 on Binary files.
3H.6 How do I keep "import" from expanding all the $\Revision$ strings
to be 1.1.1.1?
If you want to leave old RCS keywords as they are, you can use the
'-ko' trick described above. In the future, "import" might
sprout a '-ko' option of its own, so you don't have to execute two
commands.
#3H.7 I imported some files for the Yarg compiler that compiles files
with a suffix of ".yarg" and whose comment prefix is "YARG> ".
When I check them out, they will no longer compile because they
have this junk in them. Why?
YARG>YARG>YARG>YARG>YARG>YARG>YARG>YARG>YARG>YARG>YARG>YARG>YARG>
YARG> $\Log:
# Revision 1.3 1998/03/03 00:16:16 bubba
# What is 2+2 anyway?
#
# Revision 1.2 1998/03/03 00:15:15 bubba
# Added scorekeeping.
YARG>
YARG>YARG>YARG>YARG>YARG>YARG>YARG>YARG>YARG>YARG>YARG>YARG>YARG>
Well bubba, "Yarg" hasn't hit the big time yet. Neither RCS nor
CVS know about your suffix or your comment prefix. So you have
two choices:
1. Check out the Yarg-less module, and tell all the files about
your comment prefix. Visit each directory and type:
cvs admin -c"YARG> " *.yarg
If *all* files in the whole directory tree are Yarg files,
you can use this instead:
cvs admin -c"YARG> " .
Then save any changes you made, remove all the "*.yarg" files
and grab new copies from the Repository:
rm *.yarg (or: find . -name '*.yarg' -exec rm {} ';')
cvs update
It might be faster to remove the whole directory and check it
out again.
2. Change the import.c file in the CVS sources and add the .yarg
suffix, along with the "YARG> " comment prefix to the
"comtable" array.
If you ever plan to add new files with $\Log in them, you
should also go into the RCS sources and make the same change in
the table contained in the "rcsfnms.c" file.
Then delete the imported files from the Repository and
re-"import" the sources.
3H.8 How do I make "import" save the timestamps on the original files?
In the released CVS 1.3, there is no way. In the coming patch
release, there will supposedly be a '-d' option to save the dates
of the files rather than the current date.
See 4D.8 for more details.
3H.9 Why didn't "import" ignore the directories I told it to?
See 2D.11.
3H.10 Why can't I "import" 3 releases on different branches?
I'll bet you typed something like this:
cd /src/blasto.v2
cvs import -b 1.1.2 VENDOR2 Version2
cd /src/blasto.v3
cvs import -b 1.1.3 VENDOR3 Version3
cd /src/blasto.v4
cvs import -b 1.1.4 VENDOR4 Version4
This is wrong, or at least it won't help you much. You have
created three separate Vendor branches, which is probably not
what you wanted.
Earlier versions of CVS, as described in Brian Berliner's Usenix
paper, tried to support multiple Vendor branches on the theory
that you might receive source for the *same* program from multiple
vendors. It turns out that this is very rare, whereas the need to
branch in *your* development, for releases and for project
branches, is much greater.
So the model now is to use a single vendor branch to contain a
series of releases from the same vendor. Your work moves along
on the Main Trunk, or on a CVS branch to support a real
"branch in development".
To set this up, you should type this instead of the above:
cd /src/blasto.v2
cvs import VENDOR Version2
cd /src/blasto.v3
cvs import VENDOR Version3
cd /src/blasto.v4
cvs import VENDOR Version4
3H.11 What do I do if the Vendor adds or deletes files between releases?
Added files show up with no extra effort. To handle "removed"
files, you should always compare the tree structure of the new
release against the one you have in your Repository. If the
Vendor has removed files since the previous release, go into a
working directory containing your current version of the sources
and "remove" (followed by "commit" to make it really take effect)
each file that is no longer in the latest release.
Using this scheme will allow you to "checkout" any version of
the vendor's code, with the correct revisions and files, by
using "checkout -r Version[234]".
3H.12 What about if the Vendor changes the names of files or
directories, or rearranges the whole structure between releases?
Currently CVS can't handle this cleanly. It requires
"renaming" a bunch of files or directories.
See 4B.9 on "renaming" for more details.
What I generally do is to close the Repository for a while and
make changes in both the Repository and in a copy of the vendor
release until the structure matches, then execute the import.
If you ever have to check out and build an old version, you may
have to use the new, or completely different Makefiles.
3H.13 I thought "import" was for Vendor releases, why would I use it
for code of my own? Do I have to use import?
For code you produce yourself, "import" is a convenience for
fast insertion. It is not necessary. You can just as easily
checkin all the files using the RCS "ci" command and move the
resulting ",v" files into the Repository.
See Section 4B, on Setting up and Managing the Repository.
=3H.14 How do I import a large Vendor release?
When the sum of the changes made by the Vendor and the changes
made by local developers is small, "import" is not a big
problem. But when you are managing a large Repository, any care
taken up front will save you time later.
First read the following, then, before executing "import", see the
questions in Section 4C dealing with branch merges and Vendor
branch merges.
1. The first step is to make sure the structure of the new files
matches the structure of the current Repository.
Run "find . -print | sort" on both trees and "diff" the output.
2. Alter the "source" tree until the "diff" (of the list of
filenames, not of the whole trees) shows that the directory
structures are equivalent.
The "comm" command, if you have it, can help figure out what
has been added or deleted between releases.
3. If they deleted any files, you can handle them cleanly with
"cvs remove". The command "comm -23 files.old files.new" will
show you a list of files that need to be removed.
4. If they renamed any files, see 4B.9 on renaming files.
5. When you have dealt with removed and renamed files, then you
can execute the import:
cd <new source>
cvs import -m "Message" <repos> <VendorTag> <ReleaseTag>
Where
Message is the log message to be stored in the RCS files.
<repos> is a relative path to a directory within the
Repository. The directory <new source> must be at
the same relative level within the new sources as
the <repos> you give is within the Repository. (I
realize this is not obvious. Experiment first.)
<VendorTag> is a Tag used to identify the Vendor who sent you
the files you are importing. All "imports" into
the same <repos> *must* use the same VendorTag.
You can find it later by using the "log" command.
<ReleaseTag> is a Tag used to identify the particular release
of the software you are importing. It must be
unique and should be mnemonic -- at least include
the revision number in it. (Note: you can't use
'.' characters in a Tag. Substitute '_' or '-'.)
6. *SAVE* the output from the import command.
7. There will be six categories of files to deal with.
(Actually there are eight, but you have already dealt with
"removed" and "renamed" files.)
If this is the first "import" into a given <repos> directory,
only the first three of these ('I', 'L' and 'N') can occur.
a. Ignored file.
CVS prints: I filename
You'll need to examine it to see if it *should* have been
ignored. Alternatively, you can examine every file in the
"find" at the beginning and use the "import -I !"
option to avoid ignoring anything.
b. Symbolic link.
CVS prints: L linkname
Links are "ignored", but you'll probably want to create
a "checkout helper" function to regenerate them.
c. New file.
CVS prints: N filename
CVS creates a new file in the Repository. You don't
have to do anything to the file, but you might have to
change Makefiles to refer to it.
d. A file unchanged by the Vendor since its last release.
CVS prints: U filename
CVS will notice this and simply add the new ReleaseTag
to the latest rev on the Vendor branch.
No work will be needed by you, whether you have changed
the file or not. No one will notice anything.
e. A file changed by the Vendor, but not by you.
CVS prints: U filename
CVS should add the file onto the vendor branch and
attach the Release Tag to it.
When you next execute "update" in any working directory
you'll get the new revision.
f. A file changed by both the Vendor and by you.
CVS prints: C filename
These are the trouble files. For each of these files
(or in groups -- I usually do one directory at a
time), you must execute:
cvs update -j <PreviousReleaseTag> -j <ReleaseTag>
It will print either 'M' (if no overlaps) or 'C', if
overlaps. If a 'C' shows up, you'll need to edit the
file by hand.
Then, for every file, you'll need to execute"cvs commit".
See the part of Section 4C dealing with branch merges.
+3H.15 Explain: ERROR: cannot create link to <file>: Permission denied
This error appears when you try to execute a second (or later)
"import" into the same module from a directory to which you don't
have write access.
The "link error" is caused by a feature purposely added to
speed up the import.
Though the error message is somewhat strange, it indicates that
"import" is supposed to be executed only in writable directories.
----------------
-- Section 3I -- "log", "lo", "rlog"
----------------
**** Questions:
=3I.1 What is "log" for?
3I.2 How do I extract the log entries between two revisions?
=3I.3 How do I extract the log entries on a whole branch?
=3I.4 How do I generate ChangeLogs from RCS logs?
=3I.5 Why does "log" tell me a file was committed exactly 5 hours later
than I know it was?
**** Answers:
=3I.1 What is "log" for?
To provide an interface to the RCS "rlog" command, which displays
information about the underlying RCS files, including the revision
history and Tag (what RCS calls "symbol") list.
3I.2 How do I extract the log entries between two revisions?
If both <rev1> and <rev2> are on the same branch, you can get
what you are looking for with:
cvs log -r<rev1>:<rev2> <file>
If either <rev1> or <rev2> contain '-' characters, it will
complain and fail due to RCS's continued support of '-' as an
alternate range character.
<rev1> and <rev2> can be tag/symbol names, but they have to be
on the same branch, whether they are numeric or symbolic.
=3I.3 How do I extract the log entries on a whole branch?
cvs log -r<rev> <file>
where <rev> must be a branch revision (one with an even number
of dots) or a *non-branch* tag on a branch revision. Non-branch
tags on a branch revision are not normally attached by CVS, to add
one you will have to explicitly tag a physical branch number
within each file. Since these branch numbers are almost never the
same in different files, this command is not all that useful.
3I.4 How do I generate ChangeLogs from RCS logs?
A program called rcs2log is distributed as part of GNU Emacs 19.
This program should also appear in the CVS FTP archive.
=3I.5 Why does "log" tell me a file was committed exactly 5 hours later
than I know it was?
I can tell by this question that you were working in a time zone
that is 5 hours behind GMT (e.g. the U.S. East Coast in winter).
RCS file dates are stored in GMT to allow users in different time
zones to agree on the meaning of a timestamp. At first glance
this doesn't seem necessary, but many companies use distributed
file systems, such as NFS or AFS, across multiple timezones.
Some standard form must be used. GMT, as the "grid origin", is an
obvious candidate. The only other reasonable choice is to put the
timezone information in all the time stamps, but that changes the
RCS file format incompatibly, a step which has been avoided in the
last few RCS releases.
----------------
-- Section 3J -- "patch", "pa", "rdiff"
----------------
**** Questions:
3J.1 What is "patch" for?
3J.2 Why does "patch" include files from the Attic when I use '-D'?
3J.3 How do I make "patch" produce a patch for one or two files?
It seems to work only with modules.
**** Answers:
3J.1 What is "patch" for?
To produce a "diff" between tagged releases to be handed to the
"patch" command at other sites. This is the standard way that
source patches are distributed on the network.
3J.2 Why does "patch" include files from the Attic when I use '-D'?
See the explanation of the same problem with "update -D"
contained in section 5B.
3J.3 How do I make "patch" produce a patch for one or two files?
It seems to work only with modules.
Patch is intended for producing patches of whole modules between
releases to be distributed to remote sites. Instead of "patch",
you can use the "diff" command with the '-c' context option:
cvs diff -c -r <rev/tag> -r <rev/tag> <file1> . . .
The patch command will be able to merge such a "diff" into the
remote source files.
If the version of "diff" you are using supports the '-u' option,
to produce the more compact "Unidiff" format, the latest
revisions of the patch command understand that too.
----------------
-- Section 3K -- "release", "re", "rel"
----------------
**** Questions:
3K.1 What is "release" for?
3K.2 Why does release -d delete directories within my directory that
weren't ever in the CVS Repository?
3K.3 Why can't I reverse a "cvs checkout path/name/subdir" with a
"cvs release path/name/subdir" without an "unknown module name"?
3K.4 Why can't I "release" portions of a checked out directory? I
should be able to "release" any file or sub-directory within
my working directory.
3K.5 I removed the tree that I was about to start working on. How do I
tell cvs that I want to release it if I don't have it anymore?
3K.6 Why doesn't "release -d module" reverse a "checkout module"?
3K.7 Why can't I release a module renamed with "cvs checkout -d"?
**** Answers:
3K.1 What is "release" for?
To register that a module is no longer in use. It is intended
to reverse the effects of a "checkout" by adding a record to
the history file to balance the checkout record and by
optionally allowing you to delete the checked-out directory
associated with the module name.
3K.2 Why does release -d delete directories within my directory that
weren't ever in the CVS Repository?
A simplistic implementation. (I can say this -- I wrote it.)
The "release" function was written under the assumptions that the
"module name" is a first class, unavoidable interface to the
Repository, allowing no way to retrieve anything other than by
module name and a module is a self-contained entity with no
foreign directories allowed. Though it is easier to program that
way, many users of CVS believe the modules support to be too
primitive to allow such a limitation.
Since "release" was written, other parts of CVS broke those
assumptions. It will be upgraded slightly in the next release and
rewritten in the future.
3K.3 Why can't I reverse a "cvs checkout path/name/subdir" with a
"cvs release path/name/subdir" without an "unknown module name"?
Again, "release" is too primitive. It believes, truly
*believes* in modules, not relative paths. I can't *believe*
how many times I've been asked this. It was a hack of the
moment with a particular use in mind. I had no idea it was
going to cause so much trouble. I'll *fix* it already! :-)
3K.4 Why can't I "release" portions of a checked out directory? I
should be able to "release" any file or sub-directory within
my working directory.
Again, "release" believes in modules. Breaking it into bits
wasn't part of the plan. In the future, "release" might become
sophisticated enough to handle both the reversal of a "checkout"
and the deletion of random portions of the working directory, but
it isn't that way now.
3K.5 I removed the tree that I was about to start working on. How do I
tell cvs that I want to release it if I don't have it anymore?
See 3G.4.
3K.6 Why doesn't "release -d module" reverse a "checkout module"?
It does, if you are using "module" in a way that "release"
expects: a non-alias string in the left column of the "modules"
database.
If "module" is really an alias, or if you are using a relative
path in the place of "module", or if you renamed the directory
with the -d option in the modules file or on the "checkout"
command line, then the current version of "release" won't work.
Future versions of "release" will probably fix most of these.
3K.7 Why can't I release a module renamed with "cvs checkout -d"?
The current version of "release" doesn't know how to track the
renaming option ('-d') of the "checkout" command. It will
probably be fixed in the future.
----------------
-- Section 3L -- "remove", "rm", "delete"
----------------
**** Questions:
3L.1 What is "remove" for?
3L.2 Why doesn't "remove" work on directories when it appears to try?
3L.3 I don't like removing files. Is there another way to ignore them?
3L.4 I just removed a file. How do I resurrect it?
3L.5 Why doesn't "remove" delete the file? Instead, it prints:
cvs remove: no files removed; use `rm' to remove the file first
**** Answers:
3L.1 What is "remove" for?
To remove a file from the working branch. It removes a file from
the main branch by placing it in an "Attic" directory.
3L.2 Why doesn't "remove" work on directories when it appears to try?
Oversight. It should be able to delete an empty directory, but
you still don't have a way to remember when it was there and when
it disappeared to allow the "-D <date>" option to work.
You'll have to remove the working directory and the matching
directory in the Repository.
3L.3 I don't like removing files. Is there another way to ignore them?
There's no reason to be hasty in using the "remove" command.
If there is a way to ignore files in your build procedures, I'd
just do that. Later, when you decide that the files are really
ancient, you can execute a "remove" command to clean up.
The CVS "ignore" concept can't ignore files already in CVS.
3L.4 I just removed a file. How do I resurrect it?
If you executed "remove", but haven't typed "commit" (you can
tell this by the 'R' notation that "update" prints next to the
file), you can execute "add" to reverse the "remove".
If you followed the "remove" with a "commit", you'll have
to move it back out of the Attic by hand:
I use something like this: (csh-like syntax)
set repos = `cat CVS/Repository`
mv $repos/Attic/filename,v $repos/filename,v
(If you use relative paths in your Repository files, that first
line becomes: set repos = $CVSROOT/`cat CVS/Repository`)
While a file is in the Attic, you can't "add" another file by
the same name. To add such a file you either have to move it by
hand as in the above, or delete it from the Attic.
The main reason for the Attic is to retain files with tags in
them. If you execute: "update -r <oldtag>", files with <oldtag>
attached to some revision will be taken from the normal Repository
area and from the Attic. That's why you can't "add" a file with
the same name. "remove" only moves a file off the main branch, it
doesn't obliterate it.
3L.5 Why doesn't "remove" delete the file? Instead, it prints:
cvs remove: no files removed; use `rm' to remove the file first
Design choice. Unix software written within last decade, usually
requires an extra verification step, such as answering a question
or adding a flag on the command line. CVS currently requires that
you delete the file first.
Future versions of CVS might contain a '-f' switch that deletes
the existing file without complaining.
----------------
-- Section 3M -- "rtag", "rt", "rfreeze"
----------------
(See the "tag" section below for questions in common with "rtag".)
**** Questions:
3M.1 What is "rtag" for?
3M.2 Why would you use "rtag"? It assumes a static Repository.
**** Answers:
3M.1 What is "rtag" for?
To add a symbolic label (a "tag") to the last committed revisions
of a module directly in the Repository.
3M.2 Why would you use "rtag"? It assumes a static Repository.
Though the "tag" command is more useful in marking the
revisions you have in a particular working directory, "rtag" is
much handier for whole-Repository actions, which occur at major
release boundaries.
----------------
-- Section 3N -- "status", "st", "stat"
----------------
**** Questions:
=3N.1 What is "status" for?
3N.2 Why does "status" limit the File: at the top to 17 characters?
+3N.3 Shouldn't the status "Needs Checkout" be "Needs Update"?
**** Answers:
=3N.1 What is "status" for?
To display the status of files, including the revision and branch
you are working on and the existence of "sticky" information.
3N.2 Why does "status" limit the File: at the top to 17 characters?
Designed that way to line up with other data. You can find the
whole filename in the line beginning with "RCS version:", which is
not limited in length.
+3N.3 Shouldn't the status "Needs Checkout" be "Needs Update"?
Probably. Maybe in future revisions.
----------------
-- Section 3O -- "tag", "ta", "freeze"
----------------
**** Questions:
3O.1 What is "tag" for?
=3O.2 What is the difference between "tag" and "rtag"?
=3O.3 Why does "tag -b" not put a tag on the Branch Point revision?
How do I refer to the Branch Point?
-3O.4 So "tag" labels a bunch of files. What do you use a Tag for?
3O.5 How do I get "tag" and "rtag" to send mail the way "commit" does?
3O.6 Why can't "tag" handle the '-r' option that "rtag" takes?
-3O.7 After a "tag <tag>" in my working directory, why doesn't "checkout
-r <tag>" somewhere else produce copy of my current files?
#3O.8 Why doesn't "tag" write a history record the way "rtag" does?
**** Answers:
3O.1 What is "tag" for?
To add a symbolic label (a "tag") to the RCS files last checked
out, updated or committed in a working directory.
=3O.2 What is the difference between "tag" and "rtag"?
The end result of both commands is that a <tag>, or symbolic name,
is attached to a particular revision of a collection of files.
The differences lie in:
1. The collection of files they work on.
"rtag" works on the collection of files referred to by a
"module" name, as defined in the "modules" file.
"tag" works on files and directories in the current working
directory.
Both commands recursively follow directory hierarchies within
the named files and directories.
2. The revisions they choose to tag.
"rtag" places a tag on the latest committed revision of
each file on the branch specified by the '-r' option. By
default it tags the Main Branch.
"tag" places a tag on the BASE (i.e. last checked out, updated
or committed) revision of each file found in the working
directory.
3. A different set of command line options.
For example, "rtag" takes a "-r <oldtag>" option to retag an
existing tag. The "tag" command does not.
4. How it is logged.
Currently "rtag" records the <tag> and the module in the
"history" file, while "tag" does not.
=3O.3 Why does "tag -b" not put a tag on the Branch Point revision?
How do I refer to the Branch Point?
Design decision. If everything works perfectly, the "update -j"
command will do the merge you need and you don't need to check up
on it by playing with the branch point revision.
The '-b' option attaches a magic branch tag to allow CVS later to
figure out the branch point. The actual revision that <tag> is
attached to does not exist. References to the branch tag are
equivalent to references to the latest revision on the branch.
There is no way to refer to the branch point without adding a
non-branch tag. See 4C.3 on Creating a Branch.
-3O.4 So "tag" labels a bunch of files. What do you use a Tag for?
You use it to "checkout" the labeled collection of files as a
single object, referring to it by name.
Anywhere a revision number can be used a Tag can be used. In fact
tags are more useful because they draw a line through a collection
of files, marking a development milestone.
The way to think about a Tag is as a curve drawn through a matrix
of filename vs. revision number. Consider this:
Say we have 5 files (in some arbitrary modules, some may be in 2
or more modules by name, some may be in 2 or more modules because
of the Repository tree structure) with the following revisions:
file1 file2 file3 file4 file5
1.1 1.1 1.1 1.1 /--1.1* <-*- <tag>
1.2*- 1.2 1.2 -1.2*-
1.3 \- 1.3*- 1.3 / 1.3
1.4 \ 1.4 / 1.4
\-1.5*- 1.5
1.6
At some time in the past, the '*' versions were tagged. Think
of the <tag> as a handle attached to the curve drawn through the
tagged revisions. When you pull on the handle, you get all the
tagged revisions. Another way to look at it is that you draw a
straight line through the set of revisions you care about and
shuffle the other revisions accordingly. Like this:
file1 file2 file3 file4 file5
1.1
1.2
1.1 1.3 _
1.1 1.2 1.4 1.1 /
1.2*----1.3*----1.5*----1.2*----1.1 (--- <-- Look here
1.3 1.6 1.3 \_
1.4 1.4
1.5
I find that using these visual aids, it is much easier to
understand what a <tag> is and what it is useful for.
3O.5 How do I get "tag" and "rtag" to send mail the way "commit" does?
The "commit" command is supported by two files ("commitinfo"
and "loginfo") not used by other commands. To do logging the
same way for "tag" and "rtag" would require another file like
loginfo, which currently doesn't exist.
The "rtag" command requires a "module" entry, which can specify a
"tag" program using the "-t programname" option on the module
line.
There is no equivalent support for "tag".
3O.6 Why can't "tag" handle the '-r' option that "rtag" takes?
Oversight. The answer is probably "Fixed in a Future Release."
-3O.7 After a "tag <tag>" in my working directory, why doesn't "checkout
-r <tag>" somewhere else produce copy of my current files?
The only reason this would fail, other than misspelling the <tag>
string, is that you didn't "commit" your work before "tagging" it.
Only committed revisions may be tagged. Modified files are not
marked for later tagging.
#3O.8 Why doesn't "tag" write a history record the way "rtag" does?
The "rtag" command was originally intended to place major
"release" tags onto modules. The "tag" functionality was
developed to *move* the more significant tag when slight changes
to individual files sneaked in after the release tag was stamped
onto the Repository.
The significant event was the "rtag", which was recorded in the
"history" file for the "history -T" option to work.
It turns out that "tag" is more useful than "rtag", so the model
has changed. Future revisions of CVS will probably store both
kinds of tags in the history file.
----------------
-- Section 3P -- "update", "up", "upd"
----------------
**** Questions:
3P.1 What is "update" for?
=3P.2 What do 'U', 'M' and 'C' mean when I type "update"? Are they
different for "cvs -n update"?
3P.3 What's the difference between "update" and "checkout"?
=3P.4 Why don't I get new files when I execute "update"?
#3P.5 Why does "update" say 'M' both for plain modified files and for
successful (i.e. conflict-free) merges? Aren't they different?
=3P.6 After a merge ("update" or "update -j"), why doesn't CVS remember
the conflict and not allow you to commit the result until the
conflict is resolved?
3P.7 Is there a feature to tell me what I have changed, added and
removed without changing anything?
=3P.8 Why does "cvs update" not flag directories that are not in the
Repository as it does with new files?
3P.9 Why are all my files deleted when I execute "update"?
**** Answers:
3P.1 What is "update" for?
The "update" command is by far the most important command and is
probably also the most used command.
It has five purposes: (And many options.)
1. To display the status of your working files.
Though a plain "update" also displays the status, it does so
after possibly altering your working directory. To see the
status of your working files without changing anything, type:
cvs -n update {optional list of files}
2. To merge changes made to the branch you are working on into
your working files.
Each working directory is attached to a branch, usually the
Main branch. To merge changes made on your working branch by
other people into your working files, type:
cvs update {optional list of files}
3. To merge changes made to another branch into the branch you are
working on (your "working branch").
If you want to grab a whole branch, from the branch point,
which is assumed to be on the Main Branch, to the end of the
branch, you type:
cvs update -j <branch_tag> {optional files}
If you want to grab the changes made between two tags or
revisions, you type:
cvs update -j <tag1/rev1> -j <tag2/rev2> {optional files}
(If you are working with a single file, the Tags could also be
revisions numbers. Unless you take really unusual care to
match revision numbers across different files (a waste of time
given the way Tags work), using revision numbers in places of
the Tags for multiple files would be meaningless.)
4. To move your working directory to another branch.
A working directory is presumed to be attached to (or working
on) a particular branch, usually the Main branch. To alter
what CVS believes to be your working branch, you "move" to that
branch.
To move to a tagged branch, type:
cvs update -r <branch_tag> {optional files}
To move to the Main Branch, type:
cvs update -A {optional files}
5. To retrieve old revisions of files.
This option is similar to 4 above but you are not restricted to
using a <branch_tag>. You may specify any revision or Tag with
'-r' and get the specified revision or the tagged revision:
cvs update -r <tag/rev> {optional files}
Or you may specify any date with '-D':
cvs update -D <date> {optional files}
The '-p' option sends the revisions to standard output
(normally your terminal) rather than setting the "sticky" tag
and changing the files.
=3P.2 What do 'U', 'M' and 'C' mean when I type "update"? Are they
different for "cvs -n update"?
"cvs update" merges changes made to the Repository, since your
last "checkout", "update" or "commit", into your working files.
You can think of it as "changing your BASE revision."
"cvs update" prints lines beginning with:
'U' after replacing your unmodified file with a different
revision from the Repository.
'M' for two different reasons:
1. for files you have modified that have not changed in
the Repository.
2. after a merge, if it detected no conflicts.
'C' after a merge, if it detected conflicts.
You will need to remove the conflicts by editing the file.
Conflicts are surrounded by <<<<< and >>>>> markers.
"cvs -n update" shows what it *would* do, rather than doing it.
Or, another way of looking at it, "cvs -n update" displays the
relationship between your current BASE revisions and the latest
revisions in the Repository.
"cvs -n update" prints lines beginning with:
'U' for files you have not modified that have changed in the
Repository.
'M' for files you have modified that have not changed in the
Repository.
'C' for files you have modified that have also been changed in
the Repository.
See 4C.6 for what the letters mean when merging in from another
branch. The output is almost the same for a normal update if you
consider the Repository as the branch and your working directory
as the "trunk".
3P.3 What's the difference between "update" and "checkout"?
See 3C.4 above.
=3P.4 Why don't I get new files when I execute "update"?
There are six reasons for nothing to happen during an "update":
1. Nothing on your branch changed in the Repository.
If no one has committed anything to the branch you are working
on (normally the Main branch) since the last time you executed
"checkout", "update" or "commit", nothing will happen.
It's like shouting "xyzzy" or "plugh" in the wrong room.
2. You have a "sticky" non-branch <tag> or <date> attached to the
working files you are trying to "update".
At some time in the past you checked out or updated your
directory with the "-r <tag>" or "-D <date>" option. Until you
do it again with a different tag or date, or go back to the
Main Branch with "update -A", you will never again see any
updates.
3. The ./CVS/Entries.static file exists and you are expecting a
new file.
If your ./CVS administrative directory contains a file named
Entries.Static, no files will be checked out that aren't
already in the Entries or Entries.Static file.
4. You forgot to use the '-d' option and are looking for new
directories.
If you execute "update" without the '-d' option, it will not
create new directories that have been added to the Repository.
5. You typed "update" instead of "cvs update".
And now your disk caches are furiously being flushed by
multiple update daemons, destroying performance and proving to
management that you need more CPU power. :-)
6. Someone backed out the revision CVS thought you had in your
working directory, then committed a "replacement". CVS is now
confused because the revision in the Repository matches the
revision CVS thinks you already have. See 3B.6.
#3P.5 Why does "update" say 'M' both for plain modified files and for
successful (i.e. conflict-free) merges? Aren't they different?
A design choice. Yes, they are different internally, but that
shouldn't matter. Your files are in the same condition after the
"update" as they were before -- a "diff" will display only your
modifications. And you are expected to continue onward with the
normal cycle of "emacs" (a synonym for "edit" in most of the
civilized world) and "commit".
=3P.6 After a merge ("update" or "update -j"), why doesn't CVS remember
the conflict and not allow you to commit the result until the
conflict is resolved?
Maybe in a future release. There is a "sticky_conflict" patch you
might want to look at in the CVS FTP archive.
3P.7 Is there a feature to tell me what I have changed, added and
removed without changing anything?
The command "cvs -n update" will do exactly that.
=3P.8 Why does "cvs update" not flag directories that are not in the
Repository as it does with new files?
Design choice or oversight, take your pick. Directories are
handled specially. You can aim "update" at any random directory
and "update" will traverse the whole directory tree beneath it,
looking for CVS administrative directories. When it finds one,
"update" will perform its "normal" function.
Maybe a future release will notice a directory not under CVS,
print a '?' and skip over it.
3P.9 Why are all my files deleted when I execute "update"?
You probably executed "update -r <tag>" some time ago, then
removed <tag> from the Repository files. "update -r <tag>" will
delete a file that doesn't contain <tag>.
A way to fix this is to "cd" into your working directory and
type:
cvs update -A
If you don't want the latest revisions on the Main (or Vendor)
Branch, then decide what Tag (normal or branch) you want and type:
cvs update -r <the_tag_you_want>
Another way to make files disappear is to execute "update -D
<date>" where <date> is before the date stamped onto the first
revision in the RCS file.
===============================================
== Section 4 ==== Advanced Topics ====
===============================================
----------------
-- Section 4A -- Installing CVS
----------------
**** Questions:
#4A.1 What do I have to do before I install CVS?
4A.2 How do I configure the CVS programs?
=4A.3 What do I have to install?
-4A.4 How do I work around the merge problems in GNU diff version 2.1
or later?
**** Answers:
#4A.1 What do I have to do before I install CVS?
1. You must decide where to set up a Repository.
Though you can construct a Repository tree structure using
links and mount points, there must be a single copy of each
real file across your entire organization. You may not "rdist"
files and expect to edit both copies.
CVS does not support a truly distributed Repository. You can
have multiple Repositories, but each one must be mounted (not
copied or "rdist"ed) from a single place onto all machines
where it will be used.
Initially, a Repository takes about same amount of disk space
as the sources you want to put into it, plus a bit of overhead
for the RCS files.
See Section 4B. For multiple Repositories, see 4D.14.
2. You need a directory in everyone's $PATH variable where you can
install all the executables. /usr/local/bin is a common place.
3. You need some helper tools besides CVS such as "RCS" and a
good set of "diff" and "diff3" programs. See 1B.3 for
suggestions.
4. Make sure you have versions of all the programs mentioned in
the "cvs/src/config.h" file.
5. Though you can probably muddle along without it, you should
appoint one or more "Repository Administrators" who will be
responsible for maintaining the Repository structure,
administrative files and the "modules" interface.
Someone at your site should probably be on the info-cvs mailing
list. See 1B.5.
4A.2 How do I configure the CVS programs?
1. You should certainly start by reading the README file, the
INSTALL files and possibly the Makefiles and "cvsinit" program.
2. Edit the "config.h" file in the "src" directory.
Read it carefully.
You will need to specify a number of site-specific pieces of
information including the names of a number of functions.
Hint1: You really want to set the DIFF macro to use your
version of the GNU diff program with the '-a' option.
Ours is set to "gdiff -a".
Hint2: You want to use RCS 5.5 or greater and set the
"HAVE_RCS5" macro.
3. Execute the ./configure command.
4. Type "make".
=4A.3 What do I have to install?
1. Install the "cvs" executable and "mkmodules" from the CVS
sources. (The man page is useful too.)
2. Make sure you have versions of all the programs mentioned in
the config.h file, most of which are included in a standard
Unix system.
3. Unless you plan to reimplement RCS [:-)], you must install RCS.
4. Create the Repository (which you planned out in 4A.1) with the
"cvsinit" command at the top of the CVS sources.
5. You'll need to edit the Repository control files created by
"cvsinit".
6. Install any helper programs mentioned in the modules file.
-4A.4 How do I work around the merge problems in GNU diff version 2.1
or later?
See 4D.11.
----------------
-- Section 4B -- Setting up and Managing the Repository
----------------
**** Questions:
=4B.1 What do I do first? How do I create a Repository?
=4B.2 What are those files in $CVSROOT/CVSROOT?
4B.3 Is there any other state stored in the Repository besides in the
$CVSROOT/CVSROOT directory?
4B.4 How do I put sources into the Repository?
=4B.5 What file permissions should I use on (and in) the Repository?
=4B.6 How do I structure my Repository?
=4B.7 How do I manage the modules file?
4B.8 Why would anyone use "modules"? They are too restrictive. I
want to be able to select just the files I want to edit.
=4B.9 How do I rename a file or directory? What are the consequences?
=4B.10 What are "Attic" directories?
4B.11 Is it OK to remove anything from the Repository?
4B.12 Can I convert to CVS from RCS without losing my revision history?
=4B.13 Can I move RCS files with branches in them into the Repository?
=4B.14 Can I use raw RCS commands on the Repository?
4B.15 How do I convert from SCCS to RCS?
=4B.16 How do I limit access to the Repository?
=4B.17 What are the Repository Administrator's responsibilities?
4B.18 How do I move the whole Repository?
+4B.19 How do I change permissions on a file in the Repository by using
a CVS command? (i.e. without using "chmod 777 $CVSROOT/dir/file")
**** Answers:
=4B.1 What do I do first? How do I create a Repository?
First, install all the programs. (See Section 4A.)
Then create a Repository by executing "cvsinit", which works only
from within the head of the CVS source directory. (It needs files
from the distribution to work.)
If you want a very primitive Repository and don't want to save a
history log, refer to modules, or use any of the "info" files for
logging, pre-commit checks, or editing templates, you can dispense
with "cvsinit" entirely. I would advise executing it.
The cvsinit program will create a short modules file containing
the module named "CVSROOT". Execute:
cvs checkout CVSROOT
and read the information stored in the files that are checked out.
You will certainly want to add modules of your own. Edit the
"modules" file and add lines to describe the items you want to
"checkout" by module name. Here's a short list that could be
used for storing a small number of GNU and PD sources:
local local
gnu local/gnu
emacs local/gnu/emacs
cvs local/gnu/cvs
public local/public
pdprog1 local/public/pdprog1
pdprog2 local/public/pdprog2
test test
junk test/junk
When you are done editing, "commit" the modules file. If you
configured CVS to use "dbm", you might have to edit and commit the
modules file twice, in order to change the pathname of the
mkmodules program in the modules file.
Try using the "import" command to insert the "junk" module
and play around until you are comfortable.
=4B.2 What are those files in $CVSROOT/CVSROOT?
There are seven Repository control (or "database") files of
interest in the CVSROOT directory:
1. commitinfo contains two columns: 1. a regular expression to
match against pathnames within the Repository and
2. a <command> to execute for matching pathnames.
When you execute "commit", CVS passes the
Repository pathname for each directory (and the
files to commit within that directory) to
<command>. If <command> exits with a non-zero
status, the commit is blocked.
A <command> associated with a pathname of
"DEFAULT" is executed if nothing else matches.
Every <command> associated with a pathname of
"ALL" is executed separately.
2. rcsinfo contains the same first column as commitinfo, but
the second column is a template file for
specifying the log entry you are required to enter
for each commit.
"DEFAULT" and "ALL" work the same as in the
commitinfo file.
3. editinfo contains the same two columns as commitinfo, but
the <command> in the second column is intended to
do some consistency checking on the commit log.
"DEFAULT" works as in commitinfo.
4. loginfo contains the same two columns as commitinfo, but
the <command> is expected to read a log message
from its standard input. The <command> can do
anything it wants with the log information, but
normally it is appended to a log file or sent to
mailing lists.
"DEFAULT" & "ALL" work the same as in commitinfo.
5. cvsignore contains "ignore" patterns that are added to the
built-in ignore list. See 2D.10.
6. history contains a stream of text records, one for each
event that the "history" command is interested
in. Though the contents of the history file can
be read, it is intended to be read and displayed
by the "history" command.
7. modules contains the "modules" database. See 1D.11, 2C.7,
4B.7 and 4B.8 for more details.
4B.3 Is there any other state stored in the Repository besides in the
$CVSROOT/CVSROOT directory?
Only in the RCS files. The Repository holds exactly two things:
the tree of RCS files (each usually ending in ",v") and the
CVSROOT directory described above.
4B.4 How do I put sources into the Repository?
There are three main ways to put files in the Repository:
1. Use the "import" command described in Section 3H.
This method is the fastest way to put trees of new code into
the Repository and the *only* way to handle source releases
from a 3rd party software vendor.
2. Use "add" followed by "commit".
This is how to add new files and directories to the Repository,
one at a time.
3. You can move RCS files directly into the Repository.
It would probably be a good idea to create directories to hold
them.
=4B.5 What file permissions should I use on (and in) the Repository?
If you run a completely open environment (which usually means that
you don't have, or don't want to waste, the time to deal with it):
- Set all directory permissions to 777.
- Have everyone set their umasks to 0.
(BTW, I don't suggest this. It am merely reporting it.)
If you are a normal Unix shop and want to use groups effectively:
- Set all the directory permissions in the Repository to 775.
(If you are using a system that handles both System V and BSD
filesystems, you might have to set the permissions to 2775.)
- Change all the groups on the directories to match the groups
you want to write to various directories.
- Make sure every user is in the appropriate groups.
- Have everyone set their umask to 002.
If you don't want non-group members to even read the files, do the
above, but change:
- Repository directory permissions to 770. (or 2770)
- umasks to 007.
If you work in an environment where people can't be trusted to
set their "umask" to something reasonable, you might want to set
the umask for them:
mv /usr/local/bin/cvs /usr/local/bin/cvs.real
cat > /usr/local/bin/cvs
#!/bin/sh
umask 2 # Or whatever your site standard is.
exec /usr/local/bin/cvs.real ${1+"$@"}
^D
[[Future versions of CVS might sprout a "umask" configuration
variable.]]
=4B.6 How do I structure my Repository?
The Repository holds your software. It can be all interrelated
or it can be a bunch of separately managed directories.
How you break a whole system down into its component parts, while
defining interfaces between them, is one aspect of "Software
Engineering", a discipline that requires the study of dozens of
strange and wonderful areas of the computer and management worlds.
CVS provides a way to keep track of changes to individual files,
a way to "tag" collections of files, and a way to "name"
collections of files and directories. That's all. Everything
else is in the way you apply it.
In other words, you should structure your Repository to match your
needs, usually tied in with the other tools you use to build,
install and distribute your work. Common needs include the
ability to:
- mount (or automount) directories from different
places in your organization.
- check out just what you need and no more.
- check out multiple sections in a fixed relation to each other.
- check out large sections to match the assumptions built into
your build system. (Makefiles?)
In my opinion, you should start small and keep everything in one
tree, placing each major sub-system into a separate directory.
Later, when you know what you are doing, you can make it more
sophisticated.
=4B.7 How do I manage the modules file?
An equivalent question might be, "How do I structure my sources?"
This can be a difficult question in that it is not purely
technical.
Generally you want to think about what pieces of your system need
to be checked out together, built as one system or tagged
consistently. You should certainly make module names that
correspond to complete, buildable collections that you would tag
and release as one "product". It is also convenient to create
module names for small sections containing files that will usually
be worked on at the same time by the same person.
Once you have defined the structure of your work, you can usually
see how to lay it out in a Repository. After that the modules
file is easy. You set up module names and aliases to match what
you need to check out by name. If you like relative directories,
it is possible, but not recommended, to work completely without a
modules file. See 1D.11 and 2C.7.
4B.8 Why would anyone use "modules"? They are too restrictive. I
want to be able to select just the files I want to edit.
Any form of structure is restrictive. If you believe that total
chaos is a viable working paradigm, or if you believe you can keep
track of the interrelations between all portions of your
Repository in your head, then you can do what you please.
If you believe that systems of files require management and
structure, then the "modules" idea is very useful. It is a way
to impose a naming scheme on a tree of files, a naming scheme that
can be simpler than a large list of relative pathnames.
The "modules" file represents a published interface to the
Repository set up by your Repository Administrator. If s/he did a
creditable job, the modules offered will be internally consistent
and will smoothly interact with the rest of your environment.
=4B.9 How do I rename a file or directory? What are the consequences?
In CVS 1.3 there is no single CVS "rename" command.
See 2C.4 for the suggested way to rename a file or directory.
The rest of this section covers some of the consequences of
renaming.
A "renaming database" has been proposed that would keep track
of name changes so that "update -r <tag>" would continue to
work across the renaming. But as it stands, you have to pick
one of the following options:
1. Use the technique described in 2C.4. (For each file, duplicate
the file in the Repository, "remove" the old version so it
winds up in the Attic and strip all Tags off the new version.)
- "update -r <tag>" produces the correct files.
- The duplicated revision history can be slightly misleading.
- A plain (i.e. without the "-r <tag>") "checkout" or "update
-d" will create directories "renamed" this way, but you can
delete it and a plain "update" won't bring it back.
2. Move the files and directories in the Repository to the new
names.
- You save the revision history under a different file name.
- You save a little space.
- "update -r <tag>" produces the wrong files or directories.
This is not a good general solution, but if you plan never to
look back (someone may be gaining on you!), it is sometimes a
useful notion.
If you are clever with Makefiles, you might be able to rework
them to handle either the new or old names, depending on
which ones exist at the time. Then you can move an old <tag>
onto the new, more sophisticated, revision of the Makefile.
(Yes, this changes the "released" file if <tag> indicates a
release. But it is an option.)
- Important Note: If you rename a directory, you must rename
the corresponding directory in every checked-out working
directory. At the same time, you must edit the pathname
stored in the ./CVS/Repository file within each of the moved
directories.
The easiest way to move a lot of directories around is to
tell everyone to remove their working directories and check
them out again from scratch.
- The file exists in the working directory and in the
./CVS/Entries file, but not in the Repository. For the old
file, "update" prints:
cvs update: xyz.c is no longer in the repository
and deletes the file. If the file was modified, "update"
prints:
cvs update: conflict: xyz.c is modified but
no longer in the repository
C xyz.c
and leaves the file alone. In the new directory, you see:
U xyz.c
as you would if someone else executed "add" and "commit".
3. For each file, copy the working file to a new name, "remove"
the old file and "add" the new one. Since there is no way (in
CVS 1.3) to remove a directory, this only works for files.
- This is what most people think of first. Without a "rename"
command, the remove/add technique seems obvious.
- You lose the connection of your new working file to its past
revision history.
=4B.10 What are "Attic" directories?
When you use the "remove" command on a file, CVS doesn't delete
the file, it only registers your desire to delete it.
When you "commit" a removed file, CVS moves the Repository's
matching RCS file into a sub-directory named "Attic" within the
Repository.
Attic files are examined when the '-r' or '-D' option is used
on "checkout" or "update". If the specified revision, tag or
date matches one on a file in the Attic, that file is checked out
with the others.
You can think of the Attic as a sort of dead branch, which is only
looked at when you refer to a <tag> or <date>.
4B.11 Is it OK to remove anything from the Repository?
In general, removing anything from the Repository is a bad idea.
The information in a deleted object is lost forever. There are
many ways to skip over files, directories and revisions without
deleting them.
Here are some of the consequences of removing the following things
stored in the Repository:
1. CVSROOT files (Repository control files)
The Repository will work without any of them, but you should
understand what you are losing by deleting them. See 4B.2.
2. Revisions
The only way to remove revisions is to use the "admin -o"
command (or the equivalent RCS command "rcs -o").
They are lost forever. Any tags formerly attached to deleted
revisions are now pointing into Outer Space.
3. Files
You should not remove a file unless you truly never want to see
it again. If you want to be able to check out an old revision
of this file, use "cvs remove" instead.
4. Tags
Tags take up little space and you can't recover from deleting
them. If you depend on tags for releases you will lose vital
information.
5. Directories
There is no Attic for directories, so the only way to remove
them is to use "rm -r". They are gone forever.
If you delete (or move) a directory, all checked-out versions
of that directory will cause CVS to halt. You'll have to visit
each checked-out directory and remove the matching working
directory by hand.
6. Attic files
The "remove" command sends files to the Attic. To really
delete them, you have to go into the Attic and use "rm".
If a file in the Attic has a Tag on it that you might ever want
to check out again, you probably don't want to delete it.
7. Lock files (named: "#cvs.[wr]fl.<pid>")
These are lock files. If you are getting "lock" errors and
the dates on the lock files indicate that they are old, you can
delete them.
Deleting lock files still in use by a CVS process might produce
unusual errors.
4B.12 Can I convert to CVS from RCS without losing my revision history?
Yes, you can simply move (or copy) your RCS files into a directory
within the Repository, check out that directory and start working.
=4B.13 Can I move RCS files with branches in them into the Repository?
Yes, but they may not work if you created branches in a way that
conflicts with CVS's assumptions:
1. You can't use .0. branches. (They are reserved for "Magic"
branch tags.)
2. If you use branch 1.1.1, you can't use the Vendor branch.
You can use other RCS branches under CVS. There is no need to
create "magic" branch tags because the physical branch already
exists.
=4B.14 Can I use raw RCS commands on the Repository?
You can use raw rcs commands directly on the Repository if you
take a little care. The Repository itself contains no "CVS state"
(as opposed to RCS revision histories) outside the CVSROOT
directory.
But using raw RCS commands to change branches, tags or other
things that CVS depends on may render the files unusable.
See 4D.7 on RCS/CVS sharing of the Repository and Section 3B on
the "admin" command.
4B.15 How do I convert from SCCS to RCS?
You'll have to execute something like "sccs2rcs" (in the CVS
contrib directory) on every file. Then you can move the resulting
RCS files into the Repository as described above.
=4B.16 How do I limit access to the Repository?
There are all sorts of ways to restrict access to Repository
files, none of which are hooked directly into CVS. You can:
1. Set Unix groups and permissions. See 4B.5.
2. Try the "setgid" trick described in 4D.16.
3. Catch every commit using the "commitinfo" file.
4. Try to use the RCS access control lists, though I don't
think CVS will handle them cleanly.
5. Edit the source code to CVS.
=4B.17 What are the Repository Administrator's responsibilities?
Generally, the Administrator should set "policy", create the
Repository and monitor its size and control files.
Some specific responsibilities include:
1. Examining the Repository once in a while to clean up:
a. Trash files left by misguided developers who mistake the
Repository for a working directory.
b. Non-RCS files. Other than the files CVS needs in the
$CVSROOT/CVSROOT directory, everything in the Repository
should be "under" CVS.
c. Lock files (both CVS '#*' and RCS ',*' files) left around
after crashes.
d. Wrong permissions, groups and ownerships.
e. Locked files. (RCS locks, that is.)
f. Attic files that should never have been under CVS at all.
Don't blindly delete files from Attic directories -- they
were mostly put there (via the "cvs remove") for a reason.
Files that should be deleted are binary files (e.g. '*.o',
'core', executables) that were mistakenly inserted by
"import -I !".
2. Maintaining the modules file.
3. Maintaining the other Repository control files: commitinfo,
loginfo, rcsinfo and editinfo files.
4. Storing site-specific ignore patterns in the "cvsignore" file.
5. Pruning the history file every once in a while. (Try the
"cln_hist.pl" script in the "contrib" directory.)
6. Staying aware of developments on the info-cvs mailing list and
what is available in the FTP archive.
7. Run "ps ax" once in a while and kill off any "update"
programs not running as "root". It is too easy to leave the
"cvs" off the front of the "cvs update" command.
8. Executing monitor programs to check the internal consistency of
the Repository files. Ideas:
a. Files that have a default RCS branch that is not 1.1.1
(From an abuse of "admin -b".)
b. Files that have only Revisions 1.1 and 1.1.1.1, with a
default branch of "MAIN". (From an abuse of "admin -o".)
c. Existing branch tags and various branch consistency checks.
4B.18 How do I move the whole Repository?
The Repository itself contains pathnames only within the files in
the CVSROOT directory. If helper functions in the modules file or
logging programs executed out of the loginfo file point into the
Repository, you'll have to change the pathnames to point to the
new Repository location.
The main change you'll have to make is to all the ./CVS/Repository
files in the checked-out working directories.
You have four choices:
1. If you can avoid changing $CVSROOT by using a symbolic link or
mount point you don't have to do anything else.
If you must change $CVSROOT, you must also tell everyone to
change the CVSROOT environment variable in all running shells
and in their '.' files where it is set. Then pick one of the
other three options that follow:
2. If all ./CVS/Repository files in all working directories
contain relative pathnames, you don't have to do anything else.
3. Have everyone "release" or delete their working directories
(after committing, or just saving, their work) and check them
all out again from the new Repository after the move.
4. Use a PERL or shell script to run through all the
./CVS/Repository files and edit the values in the files.
+4B.19 How do I change permissions on a file in the Repository by using
a CVS command? (i.e. without using "chmod 777 $CVSROOT/dir/file")
When you first "import" or "add"/"commit" a file, the read and
execute bits on the Repository file are inherited from the
original source file, while the write bits on the Repository file
are are turned off. This is a standard RCS action.
After that, there is no way to alter the permissions on a file in
the Repository other than by changing the Repository file
directly.
Whenever you "checkout" the file or retrieve a new revision via
"update" (or after a "commit"), your working file is set to match
the permissions of the Repository file, minus any "umask" bits you
have set.
----------------
-- Section 4C -- Branching
----------------
**** Questions:
4C.1 What is a branch?
=4C.2 Why (or when) would I want to create a branch?
=4C.3 How do I create and checkout a branch?
4C.4 Once created, how do I manage a branch?
4C.5 Are there any extra issues in managing multiple branches?
4C.6 How do I merge a whole branch back into the trunk?
4C.7 How do I merge changes from the trunk into my branch or between
branches?
4C.8 How do I add a new file to a branch?
=4C.9 How do I know what branch I'm (working) on?
4C.10 Do I really have to know the name of the branch I'm working on?
4C.11 How do I refer to the revision where I branched so I can see
what changed since the Branch Point on another branch?
4C.12 Why didn't the command "cvs admin -bBRANCH1 *" create a branch?
4C.13 Is it possible to set the "default CVS branch" for everyone?
=4C.14 How do I perform a large merge?
4C.15 Is a Vendor merge any different from a branch merge?
+4C.16 How do I go back to a previous version of the code on a branch?
+4C.17 Why do I get the latest files on the branch when I tried to
"update -r <tag>"?
**** Answers:
4C.1 What is a branch?
Unfortunately, the word "branch" is an overloaded technical term.
It is used in too many different ways in three categories. It
might help to understand some of the issues by going through
the categories:
1. How Humans use the word "branch":
Most development starts with everyone working on the same
software, making changes and heading toward a single goal.
This is called something like "Main Line Development". Note
that though many people do main line development on CVS's
"Main Branch", that is a choice, not a requirement.
After a release or when one or more developers want to go off
and work on some project for a while, the Software Engineers
assigned to deal with large software issues generate a "Branch
in Development" to support the release or project. (Keep in
mind that a programmer is no more a Software Engineer than a
carpenter is a Civil Engineer.)
Essentially, the word "branch" implies a way to allow
simultaneous development on the same files by multiple people.
The above terms are human-oriented. They refer to actions
that people would like to take. They do *not* imply any
particular implementation or set of procedures. Branches in
development can be supported in many different ways.
2. How CVS uses the word "branch":
CVS uses the word "branch" in a number of ways. The two most
important are:
- The vendor branch holds releases from (normally) an
outside software vendor. It is implemented using a
specific RCS branch (i.e. 1.1.1).
- The "Main Branch", which normally holds your "Main Line
Development", but is defined as the collection of
revisions you get when you "checkout" something fresh, or
when you use the '-A' option to "update".
Important Note: The CVS "Main Branch" is *not* the same as
the RCS concept with the same name. If you are using Vendor
Branches, files you have never changed are on three branches at
the same time:
- The RCS 1.1.1 branch.
- The CVS Vendor branch.
- The CVS "Main Branch".
The concepts overlap, but they are not equivalent.
In referring to CVS, "branch" can be used in four other ways:
- A CVS working directory satisfies the definition of
"branch" for a single developer -- you are on a "virtual
branch" that does not appear in any of the RCS files or
the CVS control files.
- The CVS "default branch" is the Repository source for the
collection of files in your working directory. It is
*not* the same as the RCS "default branch". Normally the
CVS default branch is the same as the CVS Main branch. If
you use the "-r <branch_tag>" option to the "checkout"
command, you will record a "sticky" tag that changes your
default branch to the one you checked out.
- A "magic" branch can be a branch that hasn't happened
yet. It is implemented by a special tag you can check out
that is not attached to a real RCS branch. When you
commit a file to a magic branch, the branch becomes real
(i.e. a physical RCS branch).
- And, of course, CVS uses "branch" to indicate a
human-oriented "branch in development".
3. How RCS uses the word "branch":
- The RCS "Main Branch" (Synonym: "The Trunk") contains a
series of two-part revision numbers separated by a single '.'
(e.g. 1.2). It is treated specially and is the initial
default branch. (The default default?)
- The RCS "Default" branch starts out attached to the RCS "Main
Branch". For RCS purposes, it can be changed to point to any
branch. Within CVS, you *must*not* alter the RCS default
branch. It is used to support the CVS idea of a "Main
Branch" and it must either point to the RCS Main Branch, or
the Vendor Branch (1.1.1) if you haven't made any changes to
the file since you executed "import".
=4C.2 Why (or when) would I want to create a branch?
Remember that you can think of your working directory as a
"branch for one". You can consider yourself to be on a branch
all the time because you can work without interfering with others
until your project (big or small) is done.
The four major situations when should create a branch are when:
1. You expect to take a long enough time or make a large enough
set of changes that the merging process will be difficult.
2. You want to be able to "commit" and "tag" your work
repeatedly without affecting others.
If you ever think you need Source Control for your own work,
but don't want your changes to affect others, create a private
branch. (Put your username in the branch tag, to make it
obvious that it is private.)
3. You need to share code among a group of developers, but not the
whole development organization working on the files.
Rather than trying to share a working directory, you can move
onto a branch and share your work with others by "committing"
your work onto the branch. Developers not working on the
branch won't see your work unless they switch to your branch or
explicitly merge your branch into theirs.
4. You need to make minor changes to a released system.
Normally a "release" is labeled by a branch tag, allowing later
work on the released files. If the release is labeled by a
non-branch tag, it is easy to add a branch tag to a previously
tagged module with the "rtag" command. If the release is not
tagged, you made a mistake. Recovery requires identifying all
revisions involved in the release and adding a tag to them.
=4C.3 How do I create and checkout a branch?
Suggested short form:
1. Attach a non-branch tag to all the revisions you want to
branch from. (i.e. the branch point revisions)
2. When you decide you really need a branch, attach a branch tag
to the same revisions marked by the non-branch tag.
3. "Checkout" or move your working directory to the branch.
Suggested short form using modules:
A1. cvs rtag <branch_point_tag> module
A2. cvs rtag -b -r <branch_point_tag> <branch_tag> module
A3. cvs checkout -r <branch_tag> module
Suggested short form using your working directory, which contains
the revisions of your working files you want to branch from:
B1. cvs tag <branch_point_tag>
B2. cvs rtag -b -r <branch_point_tag> <branch_tag> module
B3. cvs update -r <branch_tag>
The <branch_tag> is an unusual creature. It labels a branch in a
way that allows you to "checkout" the branch, to "commit" files to
the end of the branch and to refer to the end of the branch. It
does not label the base of the branch (the branch point).
Step #1 applies a non-branch tag to all the branch point revisions
in the module/directory. Though this is not strictly necessary,
if you don't add a non-branch tag to the revisions you branch
from, you won't be able to refer to the branch point in the
future.
Between steps 1 & 2 you may commit files and the result is the
same because "rtag -r <oldtag> <newtag>" applies <newtag> to the
same revision that <oldtag> is attached to. You can use this
technique to avoid attaching *any* branch tags until you need
them.
Step B2 has two important corollaries:
1. If you plan to create the branch tag before committing
anything in your working directory, you can use "cvs tag
-b <branch_tag>" instead of the "rtag" command.
2. If you have trouble figuring out what "module" to use,
remember that "module" can also mean "relative path within
the Repository." If that doesn't help, you can aim it at
whatever parent directories you believe will cover all
your files. You can even aim it at the whole Repository
($CVSROOT), if you have to. It might take some extra
time, but assuming that your Tag is a unique string and
you don't use the '-f' option to "rtag -r", "rtag" will
only add a Tag to files in which it actually *finds* the
earlier Tag.
Step 3 may occur any time after step 2. Unless you explicitly
remove them with "tag -d", the Tags are permanent.
There are two obvious ways of to choose the <branch_point_tag> and
<branch_tag> names. Since the <branch_tag> is typed by any
developer who wants to work on the branch, you should make it mean
something to them.
Style #1 presumes that the simple version string refers to a set
of designed, documented or promised features, not to a specific
set of files. In this case, you tag the branch with the generic
Version string and assume that whenever you refer to "Version",
you want the "latest" set of files associated with that Version,
including all patches. (You can substitute what ever you like for
"bp_", as long as your <branch_point_tag> is some modification of
the <branch_tag>.)
<branch_point_tag> Matching <branch_tag>
bp_V1_3 V1_3
bp_Release2-3-5 Release2-3-5
bp_Production4_5 Release4_5
Style #2 presumes that the simple version string refers to the
specific set of files used to construct the first release of
"version". In this case, you tag the branch-point revisions with
the generic Version string and assume that whenever you refer to
this Version, you want the original set of released revisions. To
get the latest patched revisions of the release, you refer to the
branch tag "latest_<branch_point_tag>". (You can substitute what
ever you like for "latest_", as long as your <branch_tag> is some
modification of the <branch_point_tag>.)
<branch_point_tag> Matching <branch_tag>
V1_3 latest_V1_3
Release2-3-5 latest_Release2-3-5
Release4_5 latest_Production4_5
In both styles you can find out what you had to change since the
original release of this Version by typing:
cvs diff -r <branch_point_tag> -r <branch_tag>
For Style 1, this is:
cvs diff -r bp_<branch_tag> -r <branch_tag>
For Style 2, this is:
cvs diff -r <branch_point_tag> -r latest_<branch_point_tag>
Notes:
- The "-r <tag>" option tells CVS to attach a "sticky tag" to
working directory (in ./CVS/Tag) and the checked-out files (on
each line of ./CVS/Entries).
- A "sticky" <tag> (including a <branch_tag>) causes most CVS
commands to act as if "-r <tag>" were on the command line.
- A "sticky" <branch_tag> indicates that the working directory
(and working files) are "on the branch".
4C.4 Once created, how do I manage a branch?
The most important thing you should know about managing a branch
is that the creation of a branch is not a lightweight act. When
you create a branch, you must also create a set of procedures to
keep track of it.
Specifically, you must:
- Remember that the branch exists. (This is non-trivial if you
create a lot of them.)
- Plan when to merge it back into the main line of development.
- Schedule the order that multiple branch merges are to be done.
- If you ever intend to merge branches into each other, instead of
limiting merges of branch work back into the "main line", you
must keep careful track of which parts of which branches have
merged into which other branches.
The simplest way to deal with branches is to limit their number,
"collapse" them back into the main line as quickly as is
reasonable and forget them. If a group wants to continue working,
tell them to create another branch off the fully merged main line.
Remember that CVS is just a tool. Over time, it will probably
handle branching better, requiring less careful attendance.
But no matter how good it becomes, the whole idea of "branching"
is a complicated management problem. Don't take it lightly.
4C.5 Are there any extra issues in managing multiple branches?
If you plan to split from the "main line" and merge back after a
time, the only problem will be scheduling the order of branch
merges. As each branch is merged, the main line must be rebuilt
and tested. Merging multiple branches (i.e. "lines of
development") before building and testing creates more problems
than you are ready for.
If you plan to collapse some branches into others, then move the
combined branches back into the main line, you have to be careful
with the revisions and tags you hand to your "update -j"
command, but it shouldn't be much trouble.
If you plan to allow every branch to incrementally take the work
done on other branches, you are creating an almost insurmountable
bookkeeping problem. Every developer will say "Hey, I can
handle taking just this little bit," but for the system as a
whole it is disaster. Try it once and see. If you are forced
into this situation, you will need to keep track of the beginning
and end points of every merge ever done. Good Luck.
4C.6 How do I merge a whole branch back into the trunk?
If you don't have a working directory, you can checkout and merge
in one command:
cvs checkout -j <branch_tag> <module>
cd <module>
If you already have a working directory:
cd <working_directory>
cvs update <== Optional, to bring it up to date.
cvs update -j <branch_tag>
CVS will print lines beginning with
'U' for files that you hadn't changed, but the branch did.
'M' for files that you changed and the branch didn't
*and* for files that you both changed that were merged
without overlaps. (This overload is unfortunate.)
'C' for files that you both changed in a way that conflicts
with each other.
You need to go edit all the 'C' files and clean up the conflicts.
Then you must commit them.
4C.7 How do I merge changes from the trunk into my branch or between
branches?
The idea is similar to the above, but since CVS doesn't treat the
main branch like other branches, you'll have to be more precise.
Check out or "update" the files you want to merge into.
Identify the two tags on the branch you want to merge from.
(Revisions don't work too well because the same revision doesn't
mean the same thing in different files.) Then type:
cvs update -j <tag1> -j <tag2>
You can use a <branch_tag> to refer to the latest revision on the
branch, but there is no built-in way to refer to the branch point.
An alternative to merging is to identify a single revision you
want, grab it by using "update -p" and commit it. If you do
merges later, you'll get overlaps, but you get your file.
In the future, (but not yet) merging from the main branch will
look something like this:
cvs update -j MAIN
cvs commit -m "Log message"
4C.8 How do I add a new file to a branch?
The obvious technique is broken in CVS 1.3. This is the way it is
supposed to work:
You are in a directory checked out (or updated) with the "-r
<branch_tag>" option. To add <file> to the branch named
<branch_tag> you type:
cvs add <file>
cvs commit <file>
Until the next release appears, you must explicitly specify the
branch_tag:
cvs add <file>
cvs commit -r <branch_tag> <file>
One not so obvious side-effect is that the file ends up in the
Attic. It wasn't added to the Main Branch so it doesn't show up
in the main part of the Repository, only in the Attic.
You can add it to the Main Branch and branch off from there onto
the side-branch this way:
1. Move the working file back to the main branch:
cvs update -A <file>
2. Add the file "normally":
cvs add <file>
cvs commit <file>
3. Branch-tag the file using the same <branch_tag> as you did on
all the other files in your directory:
cvs tag -b <branch_tag> <file>
4. And move the file back onto the branch:
cvs update -r <branch_tag> <file>
=4C.9 How do I know what branch I'm (working) on?
Type:
cvs status
and look at the "Sticky Tag" field for each file. If:
1. The *same* tag is on *every* file in your working tree, *and*
2. That tag matches the contents of the ./CVS/Tag file, *and*
3. That tag is a branch tag,
then you know what branch you are working on. You can get sticky
Tag information directly from the ./CVS/Entries file instead of
"cvs status".
If all the sticky Tags don't agree, then your directory is
temporarily inconsistent. This is a feature allowing you to make
changes (or perform merges) to individual files on multiple
branches without checking out the whole directory.
The sticky Tag on each file in the ./CVS/Entries file (as
displayed by the "status" command) indicates what branch the
working file is on. New files should be added to the Tag stored
in ./CVS/Tag, but they are not. See the above question on adding
a new file to a branch.
To force your entire working directory onto the same branch, type:
cvs update -r <branch_tag>
4C.10 Do I really have to know the name of the branch I'm working on?
If a developer can't be relied on to know what branch of
development to work on, then either the developer's manager
isn't planning branches properly or the developer has serious
problems.
I have found that one of the hardest concepts to get across to
developers (and some managers) is that "a branch in development"
(as opposed to the use of RCS branches to support some other
scheme) is a heavyweight act. Every time you create a real branch
in development, you must spawn a set of managerial procedures and
a schedule by which you plan to merge each branch into each other
branch. Unless you plan to keep it simple and collapse (by
merging and forgetting) branches quickly, they are not to be
created lightly.
In other words, if there aren't group meetings in which the branch
to be worked on is a major topic of discussion, then the group is
not managing branches properly.
We created a couple major branches a few months ago and even the
customer service people refer to the "XYZ branch" as a shorthand
for "continuing development on the XYZ project".
4C.11 How do I refer to the revision where I branched so I can see
what changed since the Branch Point on another branch?
Given the current <branch_tag> format, there is no direct way to
refer to the branch point, which is more useful in many ways
than referring to the branch, which always refers to the latest
revision on the branch.
When CVS adds a branch tag, it attaches an RCS symbol to a
non-existent revision number containing the revision number of the
branch point as a prefix. (See Section 3O, on the "tag" command.)
RCS can't use the CVS magic branch tag and many of the CVS
commands can't refer to it.
To be certain of your ability to refer to a branch point, you must
create a "branch point" tag at the same time as the Branch tag.
See 4C.3.
4C.12 Why didn't the command "cvs admin -bBRANCH1 *" create a branch?
Because your command creates an RCS branch, not a CVS branch. See
the above discussion on branches. RCS branches are used to
support CVS branches, but they are not the same. You can't act as
if you have direct control over the RCS files.
The "admin" command was placed there as a convenience to allow
you to execute raw "rcs" commands on the Repository, taking
advantage of CVS's ability to find the files in the Repository.
But you have to remember that you are using RCS commands on a
CVS Repository, which is not generally safe unless you know
exactly what CVS depends on.
For one thing, CVS insists on control of the default branch. It
is set either to the Main branch or the Vendor branch depending
on whether you have changed the Vendor's code. If you change
the default branch, you are monkeying with the internals and
you will get unexpected results.
To set your "default CVS branch" to BRANCH1, you must use
"checkout" or "update" with the "-r BRANCH1" option. Then you
have changed CVS's idea of your "default branch", which has
little to do with RCS's default branch.
4C.13 Is it possible to set the "default CVS branch" for everyone?
No. It doesn't work that way.
When using CVS, all administrative information (such as what
branch you checked out) is stored in CVS sub-directories, local to
the user. There is no global state, other than the description
and logging files in $CVSROOT/CVSROOT.
You tell "checkout" or "update", via the "-r <tag>" option,
what branch you want to check out. The default is CVS's "Main
Branch".
I don't see a problem in *designing* a new way to indicate what
branch you get by default, instead of the main one, but that's not
how it currently works.
=4C.14 How do I perform a large merge?
Large merges require a bit more planning to be able to track
what has happened in the inevitable cases where something goes
wrong. No tool can make a "merge" make perfect sense.
Though you can handle the details in many different ways, the two
ends of the spectrum of merge techniques are: gonzo and paranoid.
The gonzo method assumes that you know everything about your
sources so that recovery from failures is "just a matter of
typing." You created the branch this way:
cvs checkout <module>
cd <module>
cvs tag -b <branch_tag>
cvs update -r <branch_tag>
>>> Edit away.
cvs commit <<== Onto branch
Now you want to merge your branch back into the Main branch, you
are certain you can make it work, or at least detect all the
failures, so you dive in and hack away: (For simplicity, we will
assume you are collapsing (i.e. merging and forgetting) a
side-branch into the Main branch from your single working
directory.)
cvs update -A
cvs update -j <branch_tag>
>>> Edit the 'C' files and remove the overlaps.
>>> Edit some more to make it all compile and work.
cvs commit
Looks simple. For more details on the output from the
"update -j" command, see 3P.2 and 4C.6.
(Note: You could also checkout a whole new working directory and
perform the merge at the same time by replacing the two update
commands with "cvs checkout -j <branch_tag> <module>".
The paranoid way is more difficult, but it can catch all sorts of
problems. You created the branch this way:
cvs checkout <module>
cd <module>
cvs tag <branch_point_tag>
cvs tag -b <branch_tag>
cvs update -r <branch_tag>
>>> Edit away.
cvs commit <<== Onto branch
The extra tag command places a non-magic tag on the Branch Point,
an act that makes it easier to do "diffs" later. Now we decide
to perform the merge:
cvs tag <latest_on_branch_tag>
cvs update -A
*1* cvs diff -r <branch_point_tag> -r <latest_on_branch_tag>
>>> *1* holds all the changes on the branch.
*2* cvs diff -r <branch_point_tag> -r HEAD
>>> *2* holds the changes on the trunk since branching.
cvs tag <premerge_tag>
cvs update -j <branch_tag>
>>> Edit the 'C' files and remove the overlaps.
*3* cvs diff
>>> Verify that *3* matches *1*, except for line numbers
and overlaps.
cvs commit
cvs tag <just_merge_changes_tag>
>>> Edit some more to make it all compile and work.
cvs commit
cvs tag <after_merge_cleanup_tag>
The reason *3* and *1* match so closely is that they are the
differences between two pairs of starting points and ending points
after the same data was inserted. If they are significantly
different, you will want to figure out why.
NOTE: You will have to tell everyone to stay the hell out of the
Repository while you do this. If they commit something while you
are in the middle of a merge, your job will be much more
difficult. If they "update" at the wrong time, their work will
be randomized until you finish. It's better to call a halt.
4C.15 Is a Vendor merge any different from a branch merge?
No. In most ways, a Vendor branch is exactly the same as any
other branch. In a Vendor merge, the data is append to the branch
by the "import" command, rather than by hand-editing, but the
merge process is the same.
See the "import" command in section 3H.
+4C.16 How do I go back to a previous version of the code on a branch?
You can avoid digging into RCS revision numbers (executing "update
-r <rev>" on each file) by trying one of these:
1. Use non-branch tags as you normally would. Non-branch tags
attach to specific revisions, so a "tag <tag>" command would
mark the revisions you have in your working directory, which
are on your branch. If you need to retrieve them, use "update
-r <non-branch-tag>"
Doing this overrides the sticky <branch_tag> attached to your
working directory with a non-branch tag, which means you won't
be able to commit until you again move forward to the end of
the branch with "update -r <branch_tag>".
2. Use the "update -r <branch_tag>:<date>" trick.
This is almost like using the '-D' option, but it looks for
revisions extant on <date> only along the given branch.
As in #1, you can't commit to this kind of working area,
because it has a sticky date referring to revisions in the
middle of a branch.
3. You can branch a branch.
If you add a branch tag to file in a working directory that was
checked out on a branch, you will branch the branch. This
works just fine, though you'll have to play some games to merge
everything back together again. You'll also create 6-part
revision numbers. (They'll be 8-part revision numbers if you
branch a branch that started out with some unmodified files the
Vendor branch. Think about it. How does revision
1.2.4.2.4.2.2.1 grab you?)
+4C.17 Why do I get the latest files on the branch when I tried to
"update -r <tag>"?
If "update -r <tag>" always retrieves the latest files on a
branch, then <tag> is a branch tag. A branch tag is supposed to
be used to grab a branch to work on. Since you can't modify a
file in the middle of a branch, checking out a <branch_tag> will
give you the latest revision on the branch.
If you want to "checkout" a specific collection of revisions, you
must use a "non-branch" tag. See the first part of 4C.16.
You *can* branch off a branch, but it is rarely needed.
----------------
-- Section 4D -- Tricks of the Trade
----------------
This section covers topics ranging from simple ideas that occur to every
CVS user to time-saving procedures I consider difficult to understand.
Some are therefore dangerous. Avoid anything you don't fully understand.
**** Questions:
=4D.1 How can you even check in binary files, let alone allow CVS to
do its auto-merge trick on them?
4D.2 Can I edit the RCS (",v") files in the Repository?
4D.3 Can I edit the ./CVS/{Entries,Repository,Tag} files?
=4D.4 Someone executed "admin -o" and removed revisions to which
tags/symbols were attached. How do I fix them?
=4D.5 How do I move a magic branch tag?
4D.6 Can I use RCS locally to record my changes without making them
globally visible by committing them?
4D.7 How can I allow access to the Repository by both CVS and RCS?
=4D.8 I "updated" a file my friend "bubba" committed yesterday.
Why doesn't the file now have a modified date of yesterday?
#4D.9 While in the middle of a large "commit", how do I run other
commands, like "diff" or "stat" without seeing lock errors?
4D.10 Why does the merge occasionally resurrect lines of code?
=4D.11 Why does the merge fail when my "rcsmerge" program is
configured to use GNU diff version 2.1 or later?
4D.12 What the hell is Entries.Static?
=4D.13 Why did I get the wrong Repository in the loginfo message?
=4D.14 Can I have multiple source repositories, one for each project?
4D.15 How do I run CVS setuid so I can only allow access through the
CVS program itself?
4D.16 How about using groups and setgid() then?
4D.17 How do I use the "commitinfo" file?
4D.18 How do I use the "loginfo" files?
**** Answers:
=4D.1 How can you even check in binary files, let alone allow CVS to
do its auto-merge trick on them?
If you configure RCS and CVS to use the GNU version of diff with
the '-a' option, CVS and RCS will handle binary files. See
section 4A for configuration info.
You also need to apply the '-ko' flag to the files to avoid
expanding RCS keywords, which can be done via:
cvs admin -ko filename
(You should be able to do it by handing "import" the -ko option,
but that isn't yet in the official release.)
The only real problem occurs when "cvs update" attempts to merge
binary revisions committed elsewhere into a modified working file.
This can be a particular problem if you are trying to use CVS on
Frame or Interleaf (document processing systems) that produce
non-text output.
[[I know of no solution to this other than to keep binaries in
some text form as "source" (real binaries could be uuencoded,
documents could be stored in "exported" (something like SGML)
form.]]
4D.2 Can I edit the RCS (",v") files in the Repository?
Yes, but be very careful. The RCS files are not free-form files,
they have a structure that is easily broken by hand-editing. The
only time I would suggest doing this is to recover from emergency
failures that are difficult to deal with using CVS commands,
including the "admin" command, which can talk directly to RCS.
Though no one actively encourages the editing of RCS files, many
people have succumbed to the urge to do so when pressed for time.
The reasons given, usually with evident contrition, include:
- Editing mistakes in, or adding text to, log entries. (If you
have RCS 5.6 or later, you should use `cvs admin -m'.)
- Renaming or moving symbolic names. (You should `cvs admin -N'
instead.)
- Unlocking a file by changing the "locker" from someone else to
yourself. (It's safer to use `cvs admin -u -l'.)
- Making global changes to past history. Example: Eradicating
former employees names from old documents and Author entries.
(And someone thought the "history" command was evidence of Big
Brother! I had never realized how much help CVS/RCS could have
provided to The Ministry of Truth.)
4D.3 Can I edit the ./CVS/{Entries,Repository,Tag} files?
Yes, but with CVS 1.3 and later, there is almost no reason to edit
any of the CVS administrative files.
If you move pieces of your Repository around it can be faster to
edit all the ./CVS/Repository files rather than checking out a
large tree. But that is nearly the only reason to do so.
=4D.4 Someone executed "admin -o" and removed revisions to which
tags/symbols were attached. How do I fix them?
It depends on what you mean by "fix". I can think of three ways
to fix your predicament:
1. Remove the tags.
Assuming you really wanted to get rid of the revision and its
associated tags, you can remove them with the "admin" command.
The "tag -d" command will only remove tags attached to existing
revisions. You can remove a tag, even if it is attached to a
non-existent filename, by typing:
cvs admin -N<tag> <file>
2. Retrieve the outdated revision.
Using CVS and RCS, there is no way to reconstruct an outdated
revision. You will have to resort to backups.
3. Move the Tags to another revision in each file.
If you want to move the tags to another valid revision, you
have two choices, both of which require that you find all the
revision numbers of the files you want to "tag" and execute the
following command sequences on each <file>.
a. Use "update" to grab the revision you want, then
execute a normal "tag" command to Tag that revision:
cvs update -r <rev> <file>
cvs tag <tag> <file>
b. Use "admin" to set the tag to a specific revision:
cvs admin -N<tag>:<rev> <file>
=4D.5 How do I move a magic branch tag?
If the <branch_tag> refers to a physical branch within an RCS
file, renaming a tag will make the existing branch in the file
seem to disappear. This is not a good idea.
If the magic branch has never had a revision committed to it, you
can move the branch by re-executing the "tag" or "rtag" command
that created it. The <branch_tag> will be moved to the place
where it would have appeared if you were tagging the file for the
first time.
4D.6 Can I use RCS locally to record my changes without making them
globally visible by committing them?
You can, but it will probably confuse CVS to have ",v" files in
your working directory. And you will lose all your log entries
when you finally commit it.
Your best bet is to create your own CVS branch and work there.
You can commit as many revisions as you want, then merge it back
into the main line when you are finished.
4D.7 How can I allow access to the Repository by both CVS and RCS?
The first step is to try not to. If some people are using CVS,
there is no reason for everyone not to. It is not hard to learn
the basics and CVS makes certain operations *easier* than a series
of RCS commands. Personal preference in what software tools can
be applied to a shared Repository has to take second place to
system integration needs. If you disagree, try writing some Lisp
code for inclusion in your Unix kernel and see what kind of
reception you get.
If you really must allow routine RCS access to the CVS Repository,
you can link an RCS sub-directory into a piece of the Repository:
ln -s /Repository/some/directory/I/want RCS
and RCS will work just fine.
Those who are using RCS will have to keep the following in mind:
1. If a file was originally added to the Repository by "import"
and has not been changed using CVS, the *RCS* default branch
will remain attached to the Vendor branch, causing revisions
checked-in by "ci" to wind up on the Vendor branch, instead of
the main branch. Only CVS moves the RCS default branch on
first commit.
The way around this is to checkin (using "ci") all the files
first and move them into the Repository. That way they won't
have Vendor branches. Then RCS will work OK.
2. It is possible to use "rcs" and "ci" to make the files unusable
by CVS. The same is true of the CVS "admin" command.
3. Normal RCS practice locks a file on checkout with "co -l". In
such an environment, RCS users should plan to keep survival
gear and food for at least 30 days near their desks. When
faced with bizarre and unexpected permission errors, howling
mobs of slavering CVS users will run the RCS users out of town
with pitchforks and machetes.
4. Though files checked in by RCS users will correctly cause
"up-to-date" failures during CVS "commits" and they will be
auto-merged into CVS working directories during "update", the
opposite won't happen.
RCS users will get no warning and will not be required to merge
older work into their code. They can easily checkin an old
file on top of a new revision added by CVS, discarding work.
See the howling mob scenario described above.
RCS is great. I have used it for years. But I wouldn't mix it
this way. In a two-camp society, you are asking for real trouble,
both in technical hassles to clean up and in political hassles to
soothe.
=4D.8 I "updated" a file my friend "bubba" committed yesterday.
Why doesn't the file now have a modified date of yesterday?
CVS restores dates from the RCS files only on first "checkout".
After that, it is more important to maintain a timestamp relative
to the other files in the working directory.
Example: I commit a source file at 5PM. You commit the same file
at 6PM. At 7PM, I compile my file. Then I execute "update". If
CVS sets the date to the one in the RCS file, the file would be
given a timestamp of 6PM and my Makefile wouldn't rebuild anything
that depended on it. Bad news.
Note that the same logic applies to retrieving a revision out of
the repository to replace a deleted file. If CVS changes your
file in an existing working directory, whether it was because a
new revision was committed by someone else or because you deleted
your working file, the timestamp on the retrieved working file
*must* be set to the current time.
When you first retrieve a file, there is no reason to expect any
particular timestamp on the file within your working area. But
later, when dependency checking is performed during a build, it is
more important for the timestamps on the local files to be
consistent with each other than than it is for working files to
match the timestamps on the files in the Repository.
#4D.9 While in the middle of a large "commit", how do I run other
commands, like "diff" or "stat" without seeing lock errors?
Type:
cvs -n <command>
The '-n' option to the main cvs command turns off lock checking, a
reasonable act given the promise offered by '-n' not to alter
anything. The "diff", "log" and "stat" commands all provide the
same information with and without the '-n' option.
Warning: Ignoring locks can produce inconsistent information
across a collection of files if you are looking at the revisions
affected by an active commit. Be careful when creating "patches"
from the output of "cvs -n diff". If you are looking only at your
working files, tagged revisions, and BASE revisions (revisions
whose numbers are read from your CVS/Entries files), you should
get consistent results. Of course, if you catch a single file in
the middle of RCS activity, you might get some strange errors.
Note that this is "cvs -n <command>". The visually similar
command "cvs <command> -n" has no relation to the former usage and
has an entirely different meaning for each command.
"cvs -n update" also works in the middle of a commit, providing
slightly different information from a plain "cvs update". But, of
course, it also avoids modifying anything.
You could also use the RCS functions, "rlog" and "rcsdiff" to
display some of the information by referring directly to the
Repository files.
You need RCS version 5 or later for the commands described above
to work entirely reliably.
4D.10 Why does the merge occasionally resurrect lines of code?
The diff3 program provided by GNU diff version 1.15 has a bug
that occasionally causes text to come back from the dead.
If you plan to upgrade to the latest GNU diff program, see the
next question.
=4D.11 Why does the merge fail when my "rcsmerge" program is
configured to use GNU diff version 2.1 or later?
A change in the overlap format was introduced in GNU diff3
between versions 2.0 and 2.1.
To get consistent rcsmerge behavior, you have four choices:
1. Go back to using GNU diff 1.15 or 2.0. If you want to use
GNU diff 2.1 or later, you'll have to pick one of the other
three choices in this list.
2. Grab RCS version 5.6.0.1 from an FSF archive and set the
DIFF3_A macro to '1' as it tells you to in the Makefile:
#define DIFF3_A 1
3. Patch the RCS 5.6 source. Change line 84 in "merger.c" from:
DIFF3, "-am", "-L", label[0], "-L", label[1],
to
DIFF3, "-amE", "-L", label[0], "-L", "", "-L", label[1],
4. Wait both for RCS version 5.7 to be released and for a new
version of CVS that can deal with it.
4D.12 What the hell is Entries.Static?
Each ./CVS administrative directory contains an Entries file,
listing the files under CVS in the directory above it. If a new
file is added to the Repository, an "update" command copies it
out of the Repository and adds it to the Entries file.
If your ./CVS directory has an Entries.Static file in it, CVS
checks it before bringing new files out of the Repository. If a
new file is *not* in Entries.Static, it is not checked out.
The Entries.Static file is created by checking out something that
doesn't include all files in a directory. Without an
Entries.Static file, the first "update" would bring more files
out of the Repository.
Examples:
- A multi-module checkout renamed with the "checkout -d" option.
- Checking out a module specified with directory and filenames.
The Entries.Static file is removed by an "update" with the
'-A', '-r' or '-D' option.
=4D.13 Why did I get the wrong Repository in the loginfo message?
You probably:
- Use multiple Repositories.
- Configured CVS to use absolute pathnames in the
./CVS/Repository file.
- Typed the "commit" command in one Repository with your
$CVSROOT pointing at the other.
"commit" and all other CVS commands will heed an absolute pathname
in the ./CVS/Repository file (or in the "-d CVSrootdir" override),
but the log function doesn't take arguments -- it just looks at
$CVSROOT.
=4D.14 Can I have multiple source repositories, one for each project?
Yes, you can have as many Repositories as you like. But each
Repository must be managed separately, creating additional work.
Question 4A.1 provides a short description of setting up a
single Repository. A few additional considerations:
1. It is a good idea to start by creating a single Repository and
split it up (or create additional Repositories) only if you
believe it is really necessary. I would only create a new
Repository if the data is completely disconnected from the rest
of the main Repository.
2. If there is a lot of overlap among the developers working on
the collections of files you want to place in different
Repositories, or if there is any connection between those
collections, I would go out of my way to create a single
Repository. It is much easier to manage.
3. Disk space should not be a factor since you can build up a
Repository using symbolic links and/or remote mounts.
4. Each Repository is completely distinct. You can't check out
modules from different Repositories at the same time. A better
way of looking at it is that if you *can* check out two modules
or directories with a single "checkout" command (without
contortions or explicit absolute pathnames), then they are in
the same Repository.
5. To "checkout" modules from multiple Repositories, you must use
the "cvs -d" option on all CVS commands or alter your $CVSROOT
variable when you change focus to another Repository. If you
work with multiple Repositories, it is a good idea to configure
CVS to use absolute pathnames in the ./CVS/Repository file,
since most commands (other than "checkout") will use that file
rather than $CVSROOT.
6. If you configure CVS to use relative pathnames in your
./CVS/Repository files, you must always be careful to set your
$CVSROOT properly or you will get unexpected results.
One monster of an unexpected result can happen when you have
two modules or directories by the same name at the same
relative path inside the Repository, in two different
Repositories. You can update a directory with completely
unrelated files. This is not a fanciful example -- a
Repository is occasionally duplicated for release purposes in
which case *all* the paths in the two Repositories are the
same.
4D.15 How do I run CVS setuid so I can only allow access through the
CVS program itself?
Setuid to root is not a great idea. Any program that modifies
files and is used by a widely distributed group of users is not a
good candidate for a setuid program. (The worst suggestion I've
ever heard was to make *Emacs* setuid to root.)
Root access on Unix is too powerful. Also, it might not work in
some (secure?) environments.
Running it setuid to some user other than root might work, if you
add this line to main.c near the beginning:
setuid(geteuid());
Otherwise it uses *your* access rights, rather than the effective
uid's.
Also, you have to invent a fake user whose name will show up in
various places. But many sites, especially those who might want a
setuid CVS for "security", want personal accountability -- no
generic accounts. I don't know whether accountability outweighs
file security.
And finally, unless you take action to limit the "admin"
command, you are leaving yourself unprotected anyway.
4D.16 How about using groups and setgid() then?
Here is a way to run CVS setgid in some environments:
0. Stick this near the front of the main() in main.c:
setgid(getegid());
This will allow "access" to work on systems where it
only works on the real gid.
1. Create a group named "cvsg", for example. Name it as you wish.
2. Put *no* users in the "cvsg" group. You can put Repository
administrators in this group, if you really want to.
3. Set the cvs executable to setgid (not setuid):
cd /usr/local/bin; chown root.cvsg cvs; chmod 2755 cvs
4. Make sure every file in the Repository is in group "cvsg":
chown -R root.cvsg $CVSROOT
5. Change all directory permissions to 770. This allows all
access to the files by the "cvsg" group (which has no members!)
and no access at all to anyone else.
find $CVSROOT -type d -exec chmod 2770 {} \;
This should allow only the cvs program (or other setgid to group
cvsg) programs to write into the area, but no one else. Yes the
user winds up owning the file, but s/he can't find it again later
since s/he can't traverse the tree. (If you allow the world
execute bit (octal 001) on directories, the user who last wrote
the file can still write to it.)
If you want to allow read access, check out an entire tree
somewhere. You have to do this anyway to build it.
Note: If you are using a stupid file system that can't inherit
file groups from the parent directory (even with the "setgid"
(Octal 2000) bit set), you might have to modify CVS (or RCS) to
reset the group every time you create a new file. I have not
tested this.
The setgid() method shares the "admin" problem with the
setuid() method.
4D.17 How do I use the "commitinfo" file?
Go read 4B.2 first.
The "commitinfo" file allows you to execute "sanity check"
functions before allowing a commit. If the function exits with a
non-zero status, the commit is denied.
To fill out a "commitinfo" file, ask yourself (and those sharing
your Repository) these questions:
- Is there anything you want to check or change before someone is
allowed to commit a file? If not, forget commitinfo.
- Do you want to execute the same exact thing before committing to
every file in the Repository? (This is useful if you want to
program the restrictions yourself.) If so, set up a single line
in the commitinfo:
DEFAULT /absolute/path/to/program
CVS executes the program once for each directory that "commit"
traverses, passing as arguments the directory and the files to
be committed within that directory.
Write your program accordingly.
- Do you want a different kind of sanity check performed for
different directories? If so, you'll have to decide what to do
for all directories and enter lines like this:
regexp1 /absolute/path/to/program-for-regexp1
regexp2 /absolute/path/to/program-for-regexp2
DEFAULT /absolute/path/to/program-for-all-else
- Is there anything you want to happen before *all* commits, in
addition to other pattern matches? If so, include a line like
this:
ALL /absolute/path/to/program
It is executed independently of all the above. And it's
repeatable as many times as you like.
4D.18 How do I use the "loginfo" files?
See 4B.2 and the "commitinfo" question above.
The "loginfo" file has the same format as the "commitinfo"
file, but its function is different. Where the "commitinfo"
information is used before a commit, the "loginfo" file is used
after a commit.
All the commands in the "loginfo" file should read data from
standard input, then either append it to a file or send a message
to a mailing list. If you want to make it simple, you can put
shell (the shell used by "popen") command lines directly in the
"loginfo" (or "commitinfo") file. These seem to work:
^special /usr/ucb/Mail -s %s special-mailing-list
^other /usr/ucb/Mail -s %s other-mailing-list
DEFAULT (echo '===='; echo %s; cat) > /path/name/to/log/file
----------------
-- Section 4E -- Weirdness
----------------
**** Questions:
4E.1 Explain: "ci error: unexpected EOF in diff output"
=4E.2 Explain: "RCS file /Repository/module/file.c,v is in use"
=4E.3 I don't want a Vendor branch. Why can't I work on the main trunk?
4E.4 Merges can't work. I don't trust them. If you won't change it to
something I can understand, I won't use CVS.
4E.5 Explain: "co error, line 2: Missing access list"
+4E.6 Explain: "error: RCS file name `xyz .c' contains white space"
+4E.7 Explain: cvs checkout: warning: <X> is not (any longer) pertinent
**** Answers:
4E.1 Explain: "ci error: unexpected EOF in diff output"
RCS versions earlier than 5.5 print the above error when a file
does not end in a newline character. It can be caused by:
- Editing with Emacs and not using "require-final-newline".
- Committing a binary file.
- Filesystem failures (NFS!) that put nulls in your file.
The solution is to upgrade to RCS 5.5 or later. (Of course, this
won't fix filesystem failures. It will merely allow RCS (and
therefore CVS) to handle the file without error.)
=4E.2 Explain: "RCS file /Repository/module/file.c,v is in use"
This is an RCS error that occurs when its internal lock file has
been left around by an RCS command interrupted by some sort of
system crash, disk failure or SIGKILL signal.
Go into the Repository and look for files with names similar to
"file.c,v", usually starting with ',', '_' or '#'. Make
sure they are really crash remnants and do not belong to
transactions in progress -- a recent last-modified timestamp
is a good indicator of a live transaction. Delete them.
=4E.3 I don't want a Vendor branch. Why can't I work on the main trunk?
The Vendor branch is the way "import" deals with a Vendor
release. If you do it any other way, you are wasting your time.
CVS was designed to work this way.
If you are not working with 3rd party (i.e. Vendor) sources, you
can skip the "import" and either move pre-existing RCS files into
the Repository, or apply the RCS "ci" command to your source files
by hand (creating ",v" files) and move them into the Repository.
4E.4 Merges can't work. I don't trust them. If you won't change it to
something I can understand, I won't use CVS.
Some developers have the feeling that three-way merging doesn't
work. They don't trust the way the "update" command
automatically merges committed changes from the Repository into
the working file.
Experience has shown that most merges are utterly painless and
most of the rest are easily resolved. The few conflicts that
cause headaches are nearly all due to poor communication between
developers, a problem no source control system can obliterate.
Some developers were troubled in the past by flaky Unix software.
I can't say that everything is perfect, but the tools CVS depends
on (RCS and diff, mainly) are fairly solid nowadays. They work.
Since it does seem to work for most of us, the algorithm is
unlikely to change soon. Why not test it on a couple trouble
spots and if it works for you, use it for a while? Then you can
make an informed decision.
4E.5 Explain: "co error, line 2: Missing access list"
This is an error message from RCS Version 3 when it tries to read
a file created by a later version of RCS.
You should upgrade to the latest version of RCS, which is Version
5.6.0.1 as I write this.
+4E.6 Explain: "error: RCS file name `xyz .c' contains white space"
RCS 5.6 doesn't allow white space in filenames. Apparently this
restriction will be removed in RCS 5.7, but CVS may still require
that filenames have no white space in them.
+4E.7 Explain: cvs checkout: warning: <X> is not (any longer) pertinent
This message occurs in two instances:
1. When there is an entry in the ./CVS/Entries for file <X> and
there is no RCS file in the Repository to back it up.
If the working file exists, and hasn't changed (determined from
the timestamp) it is removed.
2. When you try to check out a piece of the Repository with:
cvs checkout some/place/in/repository/tree
and at least the first element of the path (i.e. "some" in the
above) exists, but some part of the rest of it does not.
The checkout command checks the modules file first for the
whole path, then for a prefix of the path as a module name. If
it doesn't find *any* portion of your path in the modules file,
it says:
cvs checkout: cannot find module `<module/path>' - ignored
If it finds some set of prefix directories, it prints the
message you see.
In practice this is usually a spelling error.
3. If the Repository files you are trying to check out or update
are not readable by you, the same problems can occur.
Check the permissions on the files involved.
----------------
-- Section 4F -- Related Software
----------------
**** Questions:
+4F.1 How do I use CVS under Emacs? Is there an Emacs cvs-mode?
+4F.2 What is GIC (Graphical Interface to CVS)?
+4F.3 What is CAVEMAN?
**** Answers:
This section covers a small handful of subsystems that connect to CVS in
some way. Most are "front ends" in that they offer a different user
interface to CVS, but use CVS to perform the normal tasks.
NOTE: The short summaries below combine details culled from public
announcements of the listed software with the personal opinions of
the author of the FAQ entry.
+4F.1 How do I use CVS under Emacs? Is there an Emacs cvs-mode?
The pcl-cvs package distributed with CVS 1.3 is an emacs package
that helps with the update/commit process. When you are ready to
update, you use the 'cvs-update' command within emacs. This
executes "update" and fills a cvs-mode buffer with a line for each
file that changed. The most helpful features are: descriptive
words for what happened (i.e. Merged or Conflict rather than 'U'),
single keys bound to diffs and commits, and the ability to mark
arbitrary groups of files, possibly from different directories,
for commit as a whole.
All the developers in my group that use emacs find pcl-cvs a much
friendlier and more helpful way to update/commit than raw cvs.
One vi user even converted to emacs just to use pcl-cvs.
Contributed by Jeffrey M Loomis
+4F.2 What is GIC (Graphical Interface to CVS)?
GIC is a window interface to CVS written in Tcl/Tk, which attempts
to hide the normal CVS command line options from novice users.
GIC works only in a single directory at a time, but it offers most
of the CVS commands you would normally use.
GIC can be obtained by anonymous ftp to
ftp.cpsc.ucalgary.ca:/pub/marwood/gic-1.0b5.tar.Z
contact
David Marwood
marwood@cpsc.ucalgary.ca
[[Does someone want to try to describe this better?]]
+4F.3 What is CAVEMAN?
CAVEMAN is a front end to CVS written in PERL providing a
collection of features desired by the site where it was developed.
- The ability to spread a "project" over multiple Repositories.
- Optional automatic tagging after each commit.
- Additional locking of files.
- Extra before and after program hooks.
- A layer of event logging.
- All sorts of error messages.
- Many changes to the semantics of commands.
It is available via anonymous ftp on llnl.gov [128.115.18.253] as
gnu/caveman_vX.Y.Z.tar.gz (The numbers X, Y, & Z vary with time.)
contact
Kathleen Dyer kdyer@llnl.gov
(510)423-6803
(510)423-5112 FAX
[[Does someone want to try to describe this better?]]
----------------
-- Section 4G -- Other Systems
----------------
**** Questions:
4G.1 I use a NeXT. Is there anything I need to know?
4G.2 I use OS/2. Is there anything I need to know?
4G.3 I use SCO Unix. Is there anything I need to know?
4G.4 I use AIX. Is there anything I need to know?
=4G.5 I use IRIX. Is there anything I need to know?
=4G.6 I use an HP system. Is there anything I need to know?
**** Answers:
Out of the box, CVS works on most varieties of Unix. Some near-Unix
systems have a few problems and non-Unix systems have a *lot* of problems.
4G.1 I use a NeXT. Is there anything I need to know?
Under NeXTSTEP 2.2, the tmpnam() function always returns the
same filename, which breaks "cvs patch". Apparently the
"mktemp()" function works OK, but you'll have to hack it up to
build something that acts like "tmpnam()".
NeXTSTEP 3.0's Interface Builder uses "nib" directories,
rather than files in previous revisions. It removes files it
doesn't recognize, making it impossible to place such a
directory under CVS -- the CVS admin directory will be removed.
[[Anything else?]]
4G.2 I use OS/2. Is there anything I need to know?
[[Well?]]
4G.3 I use SCO Unix. Is there anything I need to know?
[[Well?]]
4G.4 I use AIX. Is there anything I need to know?
[[Well?]]
=4G.5 I use IRIX. Is there anything I need to know?
If you see "uid" numbers where you would expect user names, try
adding -lsun to the link line. Without it CVS is unable to
retrieve "passwd" data through NIS.
=4G.6 I use an HP system. Is there anything I need to know?
HP distributes RCS version 3 (a circa 1983 release!) with HP-UX.
CVS does not work with RCS version 3; it requires RCS version 4
or later. Your best bet is to find the latest version of RCS
and install it somewhere.
HP-UX 8.07 has a serious bug with the mmap system call and NFS
files; the bug can crash the operating system. Make sure that
you configure RCS to avoid mmap by setting has_mmap to 0 in
RCS's conf.h. This bug is fixed in HP-UX 9.
Contributed by Paul Eggert
If using the setgid() trick described in 4D.16, you will have to
create an entry in the /etc/privgroup file to give the group
assigned to the cvs executable setgid permission (see
setprivgrp(1m)). Additionally, if you are restricting "read"
access to the Repository by limiting access to the executable
(this requires yet another group), then you will require that
/etc/logingroup exists and is configured correctly (usually it's
just alink to /etc/group).
Contributed by Dale Woolridge
=============================================
== Section 5 ==== Past & Future ====
=============================================
----------------
-- Section 5A -- Contributors
----------------
**** Questions:
5A.1 Who wrote CVS?
=5A.2 You didn't write all of this FAQ, did you?
**** Answers:
5A.1 Who wrote CVS?
Brian Berliner <berliner@sun.com> converted a collection of
scripts written by Dick Grune <dick@cs.vu.nl> into a C program,
then added all sorts of features. He continues to maintain CVS.
Jeff Polk <polk@bsdi.com> wrote much of the code added between
revisions 1.2 and 1.3. Many others were involved at some level.
Take a look at the README and the ChangeLog files in the CVS
sources for more details.
=5A.2 You didn't write all of this FAQ, did you?
In the original hunt for questions to answer (performed in
Jan/Feb, 1993), I polled hundreds of people and I rephrased all
sorts of text found on the net. Because there are so many posers
of questions, I will list only those who contribute answers or
help significantly with the content and structure of this
document.
Unless a name is included in the answer itself, I didn't use
anyone else's answers verbatim. On the other hand, I did use
ideas and information provided by many. The people whose email
postings have added to this document or who have added to my
understanding are:
Brian Berliner <berliner@sun.com>, CVS maintainer.
Paul Eggert <eggert@twinsun.com>, RCS maintainer.
Gray Watson <gray@antaire.com>
Per Cederqvist <ceder@signum.se>
Pete Clark <pclark@is.com>
all of whom have sent me copies of their tutorials
and local CVS documentation.
Additional contributors, who have sent me ideas, text, corrections
and support include (in alphabetical order):
Donald Amby <amby@mixcom.mixcom.com>
Tom Cunningham <tomc@bouwsma,sps.mot.com>
Don Dwiggins <dwig@markv.com>
Dan Franklin <dan@diamond.bbn.com>
Jeffrey M Loomis <jml@world.std.com>
Barry Margolin <barmar@think.com>
Mark K. Mellis <mkm@ncd.com>
Chris Moore <Chris.Moore@src.bae.co.uk>
Gary Oberbrunner <garyo@think.com>
Steve Turner <stevet@carrier.sps.mot.com>
Dave Wolfe <dwolfe@pffft.sps.mot.com>
Dale Woolridge <dwoolridge@cid.aes.doe.ca>
Plus a myriad Thinking Machines people who posed hundreds of
questions.
Please send corrections. If I forgot you, remind me and I'll add
your name to the list.
----------------
-- Section 5B -- Bugs and Patches
----------------
This section addresses some known bugs and patches for them.
Large patches will be stored in the FTP area.
See the Development section later for stuff being worked on.
**** Questions:
5B.1 Why can't CVS handle deletion of directories?
=5B.2 Why can't CVS handle the moving of sources from one place in the
directory hierarchy to another?
=5B.3 Why does "checkout" recurse indefinitely if an alias contains
its own name?
5B.4 When I typed "cvs update -D <date>", why did it check out all
sorts of ancient files from the Attic? Shouldn't it just create
the set of files and revisions that existed at that date?
5B.5 When I typed "cvs update -D <date>" in my branch, why did it
screw up all my files?
5B.6 When I executed "checkout" into an existing directory I got "No
such file or directory" errors. Why?
5B.7 Why does "update" send all output to the terminal after 26 files
have been updated?
+5B.8 Why doesn't the "-I !" option work in update and import?
**** Answers:
5B.1 Why can't CVS handle deletion of directories?
An oversight, probably. [[Fixed in a future release?]]
=5B.2 Why can't CVS handle the moving of sources from one place in the
directory hierarchy to another?
A "renaming database" has been proposed to track the history of
pathname changes in the Repository. A general solution is a
difficult problem. See 4B.9 and 2C.4.
=5B.3 Why does "checkout" recurse indefinitely if an alias contains
its own name?
A bug in the handling of aliases. [[I'll remove this one when
the bug is fixed.]]
5B.4 When I typed "cvs update -D <date>", why did it check out all
sorts of ancient files from the Attic? Shouldn't it just create
the set of files and revisions that existed at that date?
This seems to be a bug, but is really the lack of any obvious
place to store the date when a file is "removed".
There are four ranges of dates that CVS has to deal with when
trying to determine what revision was available on <date>:
1. Dates before the earliest revision in the file.
2. Dates between any two revisions in the file.
3. Dates between the latest revision in the file and the date
when the file was moved to the Attic by "commit".
4. Dates after moving the file to the Attic.
Since the date when a file is moved to the Attic is not stored
anywhere, CVS can't tell the difference between #3 and #4.
To avoid not producing a file that should exist in case #3, it
produces extraneous files in case #4.
For the above reason, if you have removed files in the Attic, it
is better to use "-r <tag>, or even "-r HEAD" than to use a
date spec.
5B.5 When I typed "cvs update -D <date>" in my branch, why did it
screw up all my files?
Currently, the internal routine ("version_ts") that looks up
info about a file, overrides both the tag and date if *either*
the tag or date is specified on the command line. If only the
date is specified, it should not override a branch tag, but it
does.
5B.6 When I executed "checkout" into an existing directory I got "No
such file or directory" errors. Why?
Though the man page says that "checkout" turns into an
"update -d" in directories that already exist, it is referring
to directories that already exist *and* were created by CVS.
When you try to run "checkout" on top of an existing directory
structure, some of which wasn't created by CVS, it will handle
directories and non-CVS files within directories already under
CVS, but it will display the above error on non-CVS files within
non-CVS directories.
5B.7 Why does "update" send all output to the terminal after 26 files
have been updated?
CVS uses the "tmpnam()" function to generate temporary file names.
The ANSI standard for the "tmpnam()" function says:
"The tmpnam function generates a different string each time it is
called, up to TMP_MAX times. If it is called more than TMP_MAX
times, the behavior is implementation defined."
Later it says that the value of "TMP_MAX shall be at least 25."
On some platforms, the above specification is taken literally by
turning "at least 25" into "exactly 26" and by doing something
foolish (i.e. "implementation defined") after that. Some
systems return the same name repeatedly, which causes one form of
trouble. Others return NULL or garbage, which causes a different
form of trouble.
The broken systems appear to be cycling a single character through
the alphabet. SunOS cycles 3 characters through the alphabet, so
it won't cause trouble until 26 cubed or 17576 calls to
"tmpnam()".
Since CVS doesn't depend on the exact format of the tmp files, the
workaround is to provide a "tmpnam()" that doesn't have a limit
on the number of calls to it.
+5B.8 Why doesn't the "-I !" option work in update and import?
A bug. See the patch named "unoff/import_ignore" in the CVS FTP
archive
[[Section 5B needs more, but should probably wait until the
patch release comes out. Then we can document them for real and
provide pointers to patches in the FTP area.]]
----------------
-- Section 5C -- Development
----------------
I hope to record three types of information here:
1. Plans (with the developer's name attached) for fixing larger
bugs. (Smaller bugs should just show up, with a patch or a
reference to a patch stored in the FTP archive, in the
"Bugs" section above.)
2. Plans for new development, with the developer's name attached.
(If the developer is particularly gonzo, it might also show a
completion date.)
3. Requests for ideas and code to fix unresolved issues.
**** Questions:
=5C.1 Where do I send bug reports?
=5C.2 Where do I send fixes and patches?
5C.3 Where do I send ideas for future development?
5C.4 What plans are there for fixing bugs?
=5C.5 What plans are there for new features?
=5C.6 I have some time and I'd like to help. What can I do for you?
**** Answers:
=5C.1 Where do I send bug reports?
First make sure it is a bug. Talk to your friends, coworkers and
anyone you know who uses CVS. Search this FAQ for related issues.
Then test it carefully. Try out variations to narrow down the
problem. Make sure it is repeatable. Look for workarounds so you
can report them.
If you are still sure it's a bug and you tried to fix it, skip to
the next question. Otherwise, send a message to the info-cvs
mailing list containing one of the following:
1. If you have a good repeatable case and you think you know what
is going on, then describe the problem in detail. Include
a workaround if you have one.
2. If you have no idea what is going on, go ahead and send a
question to the info-cvs mailing list. Include any information
you have describing the symptoms.
If careful testing reveals an RCS bug rather than a CVS bug, you
can sendbug reports to: rcs-bugs@cs.purdue.edu
=5C.2 Where do I send fixes and patches?
First make sure the "fix" does something useful. Have someone to
review your fix. It is better to spend a bit of one person's
thinking time than to waste the time of thousands of people trying
to understand your fix.
If you tried to fix it and the patch is small, include the patch
in your message. Make sure the patch is based on the latest
released version of CVS.
If you tried to fix it and the patch is large, you should think
about why it is so large. Did you add a generally useful feature,
or did it grow out of hand?
If you still believe it is solid, send it to the maintainer of the
FTP archive (currently the author of this FAQ) for inclusion in
the CVS FTP archive and to Brian Berliner, the maintainer of CVS.
5C.3 Where do I send ideas for future development?
[[Brian?]]
5C.4 What plans are there for fixing bugs?
David G. Grubbs <dgg@think.com> plans/hopes to:
- Fix the release command to be more sophisticated about
foreign directories, renaming and to allow the release of
anything in the working directory.
- Fix the history command to track changes made in the
underlying layers since I originally wrote it, including
making "tag" work with history.
[[Brian?]]
[[Others?]]
=5C.5 What plans are there for new features?
David G. Grubbs <dgg@think.com> plans/hopes to:
- Implement the design described in the Branching spec
distributed to this list in January, 93. It attempts to
address the problem of merging between arbitrary branches
and to fully support the idea of "branching".
- Add a feature to "cvs add" (Maybe a '-a' switch.) to
add a file by the same name as one in the Attic, by
dragging it back out of the Attic. (This connects to the
branching code, since a way has to be added to drag a
file out of the Attic that is merged onto the Main branch
from being only on a side-branch.)
- If no one else wants to deal with it, I would like to
enhance the whole "modules" concept to cover more of
the naming problem and to allow more complicated access
control. (Optional, of course.)
- Create a set of configuration files (in addition to or to
supersede the cvsignore files) to allow the setting of
a wide variety of site-specific options.
Brian Berliner <berliner@sun.com> plans/hopes to:
- [[Rename database?]]
[[Brian? Any plans?]]
Paul F. Kunz <pfkeb@slac.stanford.edu> has produced a version of
CVS (RCVS) that runs remotely.
On the host "ftp.slac.stanford.edu", you can find:
Sources: pub/sources/rcvs-0.5.0.tar.Z
Paper: pub/preprints/slac-pub-5923.ps
[[Others?]]
=5C.6 I have some time and I'd like to help. What can I do for you?
You can review this document, correct errors and fill in any of
the incomplete sections.
You can add to the contrib area, which contains useful ways to use
some of the programmable CVS facilities (loginfo, commitinfo) or
ways of connecting to work environments (pcl-cvs).
You could write a regression test suite. Or at least a scaffold
into which we can drop tests.
You can write specs for new features, fix bugs, review the man
page or . . .
[[Brian?]]
[[Is there some way we can register someone as working
on something or should we just stay in the "implement it and
send it to me" mode?]]
=================================================
== Section 6 ==== Table of Contents ====
=================================================
===========================================================================
== Frequently Asked Questions about CVS (The Concurrent Versions System) ==
===========================================================================
============================================
== Section 0 ==== Introduction ====
============================================
Questions are divided into five numbered Sections. Sections are divided
into lettered sub-sections. The questions are numbered sequentially
within each sub-section, though they are in no particular order.
1. What is CVS?
A. What is CVS? What's it for? Why CVS?
B. Where do I find it? Where can I find Help?
C. How does CVS differ from other similar software?
D. What do you mean by . . .? (Definitions)
2. User Tasks
A. Getting Started
B. Common User Tasks
C. Less Common User Tasks
D. General Questions
3. Commands
A. through P. One section for each CVS command.
4. Advanced Topics
A. Installing CVS
B. Setting up and Managing the Repository
C. Branching
D. Tricks of the Trade
E. Weirdness
F. Related Software
G. Other Systems
5. Past & Future
A. Contributors.
B. Bugs and Patches
C. Development
6. Table of Contents
============================================
== Section 1 ==== What is CVS? ====
============================================
----------------
-- Section 1A -- What is CVS? What's it for? Why CVS?
----------------
1A.1 What does CVS stand for? Can you describe it in one sentence?
1A.2 What is CVS for? What does it do for me?
1A.3 How does CVS work?
=1A.4 What is CVS useful for?
=1A.5 What is CVS *not* useful for?
=1A.6 Why isn't it called OSCO (Online Source COntrol)?
----------------
-- Section 1B -- Where do I find CVS? Where can I find Help?
----------------
1B.1 How do I get more information about CVS?
1B.2 Is there an archive of CVS material?
1B.3 How do I get a copy of the latest version of CVS?
1B.4 Is there any other documentation? How about tutorials?
1B.5 Is there a mailing list devoted to CVS? How do I get on it?
1B.6 What prayers are appropriate for each of the major denominations
(e.g. 20's, 50's, 100's) when issuing complex CVS commands?
+1B.7 How do I get files out of the archive if I don't have FTP?
----------------
-- Section 1C -- How does CVS differ from other similar software?
----------------
=1C.1 How does CVS differ from RCS?
1C.2 How does CVS differ from SCCS?
=1C.3 How does CVS differ from ClearCase?
1C.4 How does CVS differ from TeamWare?
1C.5 How does CVS differ from SunPro?
1C.6 How does CVS differ from Aegis?
1C.7 How does CVS differ from Shapetools?
+1C.8 How does CVS differ from TeamNet?
+1C.9 How does CVS differ from ProFrame?
+1C.10 How does CVS differ from CaseWare/CM?
+1C.11 How does CVS differ from Sublime?
----------------
-- Section 1D -- What do you mean by . . .? (Definitions)
----------------
#1D.1 What are "The Repository", "$CVSROOT" and "CVSROOT"?
1D.2 What is an RCS file?
1D.3 What is a working file?
1D.4 What is a working directory (or working area)?
1D.5 What is "checking out"?
=1D.6 What is a revision?
1D.7 What is a "Tag"?
=1D.8 What are "HEAD" and "BASE"?
=1D.9 What is a Branch?
=1D.10 What is "the trunk"?
=1D.11 What is a module?
+1D.12 What does "merge" mean?
==========================================
== Section 2 ==== User Tasks ====
==========================================
----------------
-- Section 2A -- Getting Started
----------------
2A.1 What is the first thing I have to know?
2A.2 Where do I work?
=2A.3 What does CVS use from my environment?
2A.4 OK, I've been told that CVS is set up, my module is named
"ralph" and I have to start editing. What do I type?
2A.5 I have been using RCS for a while. Can I convert to CVS without
losing my revision history? How about converting from SCCS?
----------------
-- Section 2B -- Common User Tasks
----------------
#2B.1 What is the absolute minimum I have to do to edit a file?
=2B.2 If I edit multiple files, must I type "commit" for each one?
2B.3 How do I get rid of the directory that "checkout" created?
=2B.4 How do I find out what has changed?
=2B.5 I just created a new file. How do I add it to the Repository?
=2B.6 How do I merge changes made by others into my working directory?
2B.7 How do I label a set of revisions so I can retrieve them later?
2B.8 How do I checkout an old release of a module, directory or file?
2B.9 What do I have to remember to do periodically?
----------------
-- Section 2C -- Less Common User Tasks
----------------
2C.1 Can I create sub-directories in my working directory?
2C.2 How do I add new sub-directories to the Repository?
2C.3 How do I remove a file I don't need?
=2C.4 How do I rename a file?
2C.5 How do I make sure that all the files and directories in my
working directory are really in the Repository?
=2C.6 How do I create a branch?
=2C.7 How do I modify the modules file? How about the other files in
the CVSROOT administrative area?
+2C.8 How do I split a file into pieces, retaining revision histories?
----------------
-- Section 2D -- General Questions
----------------
=2D.1 How do I see what CVS is trying to do?
2D.2 If I work with multiple modules, should I check them all out and
commit them occasionally? Is it OK to leave modules checked out?
2D.3 What is a "sticky" tag? What makes it sticky? How do I loosen it?
2D.4 How do I get an old revision without updating the "sticky tag"?
=2D.5 What operations disregard sticky tags?
=2D.6 Is there a way to avoid reverting my Emacs buffer after
committing a file? Is there a "cvs-mode" for Emacs?
2D.7 How does conflict resolution work? What *really* happens if two
of us change the same file?
2D.8 How can I tell who has a module checked out?
#2D.9 Where did the .#<file>.1.3 file in my working directory come from?
2D.10 What is this "ignore" stuff?
2D.11 Why does .cvsignore not ignore directories?
2D.12 Is it safe to interrupt CVS using Control-C?
2D.13 How do I turn off the "admin" command?
2D.14 How do I turn off the ability to disable history via "cvs -l"?
2D.15 How do I keep certain people from accessing certain directories?
========================================
== Section 3 ==== Commands ====
========================================
----------------
-- Section 3A -- "add", "ad", "new"
----------------
3A.1 What is "add" for?
3A.2 How do I add a new file to the branch I'm working on?
3A.3 Why did my newly added file end up in the Attic?
3A.4 How do I put a new file on the Main Branch and branch off from
there onto my default branch?
----------------
-- Section 3B -- "admin", "adm", "rcs"
----------------
3B.1 What is "admin" for?
3B.2 Wow! Isn't that dangerous?
=3B.3 What would I normally use "admin" for?
=3B.4 What should I avoid when using "admin"?
-3B.5 How do I restrict the "admin" command? The -i flag in the modules
file can restrict commits. What's the equivalent for "admin"?
+3B.6 I backed out a revision with "admin -o" and committed a
replacement. Why doesn't "update" retrieve the new revision?
----------------
-- Section 3C -- "checkout", "co", "get"
----------------
3C.1 What is "checkout" for?
3C.2 What is the "module" that "checkout" takes on the command line?
3C.3 Isn't a CVS "checkout" just a bunch of RCS checkouts?
3C.4 What's the difference between "update" and "checkout"?
3C.5 Why can't I check out a file from within my working directory?
3C.6 How do I avoid dealing with those long relative pathnames?
3C.7 Can I move a checked-out directory? Does CVS remember where it
was checked out?
#3C.8 How can I lock files on checkout the way RCS does?
+3C.9 What is "checkout -s"? How is it different from "checkout -c"?
----------------
-- Section 3D -- "commit", "ci", "com"
----------------
3D.1 What is "commit" for?
=3D.2 If I edit ten files, do I have to type "commit" ten times?
3D.3 Explain: cvs commit: Up-to-date check failed for `<file>'
3D.4 What happens if two people try to "commit" conflicting changes?
3D.5 I committed something and I don't like it. How do I remove it?
=3D.6 Explain: cvs commit: sticky tag `V3' for file `X' is not a branch
=3D.7 Why does "commit -r <branch_tag>" put new files in the attic?
+3D.8 Why does "commit -r <rev>" ignore <rev> on an added file?
----------------
-- Section 3E -- "diff", "di", "dif"
----------------
3E.1 What is "diff" for?
=3E.2 Why did "diff" display nothing when I know there are later
committed revisions in the Repository?
#3E.3 How do I display what changed in the Repository since I last
executed "checkout", "update" or "commit"?
=3E.4 How do I display the difference between my working file and what
I checked in last Thursday?
=3E.5 Why can't I pass the --unified option to "diff"?
----------------
-- Section 3F -- "export", "exp", "ex"
----------------
3F.1 What is "export" for?
=3F.2 Why does it remove the RCS keywords so I can't use the "ident"
command on the source files?
=3F.3 Can I override the '-kv' flag CVS passes to RCS?
=3F.4 Why the hell not?
3F.5 Why does "export -D" check out every file in the Attic?
----------------
-- Section 3G -- "history", "hi", "his"
----------------
3G.1 What is "history" for?
3G.2 Of what use is it?
3G.3 What is this, Big Brother?
3G.4 I deleted my working directory and "history" still says I have
it checked out. How do I fix it?
3G.5 So I *can* edit the History file?
3G.6 Why does the history file grow so quickly?
3G.7 What is the difference between "cvs history -r <tag/rev>" and
"cvs history -t <tag>"?
3G.8 Why does "cvs history -c -t <tag>" fail to print anything?
3G.9 "cvs history -a -o" only printed one line for each checked-out
module. Shouldn't it print all the directories where the
modules are checked out?
=3G.10 I can't figure out "history", can you give me concrete examples?
----------------
-- Section 3H -- "import", "im", "imp"
----------------
=3H.1 What is "import" for?
=3H.2 How am I supposed to use "import"?
=3H.3 Why does import put files on a branch? Why can't you put it on
the Main Trunk and let me work on a branch?
3H.4 Is there any way to import binary files?
=3H.5 Why does "import" corrupt some binary files?
3H.6 How do I keep "import" from expanding all the $\Revision$ strings
to be 1.1.1.1?
#3H.7 I imported some files for the Yarg compiler that compiles files
with a suffix of ".yarg" and whose comment prefix is "YARG> ".
When I check them out, they will no longer compile because they
have this junk in them. Why?
3H.8 How do I make "import" save the timestamps on the original files?
3H.9 Why didn't "import" ignore the directories I told it to?
3H.10 Why can't I "import" 3 releases on different branches?
3H.11 What do I do if the Vendor adds or deletes files between releases?
3H.12 What about if the Vendor changes the names of files or
directories, or rearranges the whole structure between releases?
3H.13 I thought "import" was for Vendor releases, why would I use it
for code of my own? Do I have to use import?
=3H.14 How do I import a large Vendor release?
+3H.15 Explain: ERROR: cannot create link to <file>: Permission denied
----------------
-- Section 3I -- "log", "lo", "rlog"
----------------
=3I.1 What is "log" for?
3I.2 How do I extract the log entries between two revisions?
=3I.3 How do I extract the log entries on a whole branch?
3I.4 How do I generate ChangeLogs from RCS logs?
=3I.5 Why does "log" tell me a file was committed exactly 5 hours later
than I know it was?
----------------
-- Section 3J -- "patch", "pa", "rdiff"
----------------
3J.1 What is "patch" for?
3J.2 Why does "patch" include files from the Attic when I use '-D'?
3J.3 How do I make "patch" produce a patch for one or two files?
It seems to work only with modules.
----------------
-- Section 3K -- "release", "re", "rel"
----------------
3K.1 What is "release" for?
3K.2 Why does release -d delete directories within my directory that
weren't ever in the CVS Repository?
3K.3 Why can't I reverse a "cvs checkout path/name/subdir" with a
"cvs release path/name/subdir" without an "unknown module name"?
3K.4 Why can't I "release" portions of a checked out directory? I
should be able to "release" any file or sub-directory within
my working directory.
3K.5 I removed the tree that I was about to start working on. How do I
tell cvs that I want to release it if I don't have it anymore?
3K.6 Why doesn't "release -d module" reverse a "checkout module"?
3K.7 Why can't I release a module renamed with "cvs checkout -d"?
----------------
-- Section 3L -- "remove", "rm", "delete"
----------------
3L.1 What is "remove" for?
3L.2 Why doesn't "remove" work on directories when it appears to try?
3L.3 I don't like removing files. Is there another way to ignore them?
3L.4 I just removed a file. How do I resurrect it?
3L.5 Why doesn't "remove" delete the file? Instead, it prints:
cvs remove: no files removed; use `rm' to remove the file first
----------------
-- Section 3M -- "rtag", "rt", "rfreeze"
----------------
3M.1 What is "rtag" for?
3M.2 Why would you use "rtag"? It assumes a static Repository.
----------------
-- Section 3N -- "status", "st", "stat"
----------------
=3N.1 What is "status" for?
3N.2 Why does "status" limit the File: at the top to 17 characters?
+3N.3 Shouldn't the status "Needs Checkout" be "Needs Update"?
----------------
-- Section 3O -- "tag", "ta", "freeze"
----------------
3O.1 What is "tag" for?
=3O.2 What is the difference between "tag" and "rtag"?
=3O.3 Why does "tag -b" not put a tag on the Branch Point revision?
How do I refer to the Branch Point?
-3O.4 So "tag" labels a bunch of files. What do you use a Tag for?
3O.5 How do I get "tag" and "rtag" to send mail the way "commit" does?
3O.6 Why can't "tag" handle the '-r' option that "rtag" takes?
-3O.7 After a "tag <tag>" in my working directory, why doesn't "checkout
-r <tag>" somewhere else produce copy of my current files?
#3O.8 Why doesn't "tag" write a history record the way "rtag" does?
----------------
-- Section 3P -- "update", "up", "upd"
----------------
3P.1 What is "update" for?
=3P.2 What do 'U', 'M' and 'C' mean when I type "update"? Are they
different for "cvs -n update"?
3P.3 What's the difference between "update" and "checkout"?
=3P.4 Why don't I get new files when I execute "update"?
#3P.5 Why does "update" say 'M' both for plain modified files and for
successful (i.e. conflict-free) merges? Aren't they different?
=3P.6 After a merge ("update" or "update -j"), why doesn't CVS remember
the conflict and not allow you to commit the result until the
conflict is resolved?
3P.7 Is there a feature to tell me what I have changed, added and
removed without changing anything?
=3P.8 Why does "cvs update" not flag directories that are not in the
Repository as it does with new files?
3P.9 Why are all my files deleted when I execute "update"?
===============================================
== Section 4 ==== Advanced Topics ====
===============================================
----------------
-- Section 4A -- Installing CVS
----------------
#4A.1 What do I have to do before I install CVS?
4A.2 How do I configure the CVS programs?
=4A.3 What do I have to install?
4A.4 How do I get around the bugs I've heard of GNU diff version 2.2?
----------------
-- Section 4B -- Setting up and Managing the Repository
----------------
=4B.1 What do I do first? How do I create a Repository?
=4B.2 What are those files in $CVSROOT/CVSROOT?
4B.3 Is there any other state stored in the Repository besides in the
$CVSROOT/CVSROOT directory?
4B.4 How do I put sources into the Repository?
=4B.5 What file permissions should I use on (and in) the Repository?
=4B.6 How do I structure my Repository?
=4B.7 How do I manage the modules file?
4B.8 Why would anyone use "modules"? They are too restrictive. I
want to be able to select just the files I want to edit.
=4B.9 How do I rename a file or directory? What are the consequences?
=4B.10 What are "Attic" directories?
4B.11 Is it OK to remove anything from the Repository?
4B.12 Can I convert to CVS from RCS without losing my revision history?
=4B.13 Can I move RCS files with branches in them into the Repository?
=4B.14 Can I use raw RCS commands on the Repository?
4B.15 How do I convert from SCCS to RCS?
=4B.16 How do I limit access to the Repository?
=4B.17 What are the Repository Administrator's responsibilities?
4B.18 How do I move the whole Repository?
+4B.19 How do I change permissions on a file in the Repository by using
a CVS command? (i.e. without using "chmod 777 $CVSROOT/dir/file")
----------------
-- Section 4C -- Branching
----------------
4C.1 What is a branch?
=4C.2 Why (or when) would I want to create a branch?
=4C.3 How do I create and checkout a branch?
4C.4 Once created, how do I manage a branch?
4C.5 Are there any extra issues in managing multiple branches?
4C.6 How do I merge a whole branch back into the trunk?
4C.7 How do I merge changes from the trunk into my branch or between
branches?
4C.8 How do I add a new file to a branch?
=4C.9 How do I know what branch I'm (working) on?
4C.10 Do I really have to know the name of the branch I'm working on?
4C.11 How do I refer to the revision where I branched so I can see
what changed since the Branch Point on another branch?
4C.12 Why didn't the command "cvs admin -bBRANCH1 *" create a branch?
4C.13 Is it possible to set the "default CVS branch" for everyone?
=4C.14 How do I perform a large merge?
4C.15 Is a Vendor merge any different from a branch merge?
+4C.16 How do I go back to a previous version of the code on a branch?
+4C.17 Why do I get the latest files on the branch when I tried to
"update -r <tag>"?
----------------
-- Section 4D -- Tricks of the Trade
----------------
=4D.1 How can you even check in binary files, let alone allow CVS to
do its auto-merge trick on them?
4D.2 Can I edit the RCS (",v") files in the Repository?
4D.3 Can I edit the ./CVS/{Entries,Repository,Tag} files?
=4D.4 Someone executed "admin -o" and removed revisions to which
tags/symbols were attached. How do I fix them?
=4D.5 How do I move a magic branch tag?
4D.6 Can I use RCS locally to record my changes without making them
globally visible by committing them?
4D.7 How can I allow access to the Repository by both CVS and RCS?
=4D.8 I "updated" a file my friend "bubba" committed yesterday.
Why doesn't the file now have a modified date of yesterday?
#4D.9 While in the middle of a large "commit", how do I run other
commands, like "diff" or "stat" without seeing lock errors?
4D.10 Why does the merge occasionally resurrect lines of code?
4D.11 Why does the merge fail when my "rcsmerge" program is
configured to use GNU diff version 2.1 or later?
4D.12 What the hell is Entries.Static?
=4D.13 Why did I get the wrong Repository in the loginfo message?
=4D.14 Can I have multiple source repositories, one for each project?
4D.15 How do I run CVS setuid so I can only allow access through the
CVS program itself?
4D.16 How about using groups and setgid() then?
4D.17 How do I use the "commitinfo" file?
4D.18 How do I use the "loginfo" files?
----------------
-- Section 4E -- Weirdness
----------------
4E.1 Explain: "ci error: unexpected EOF in diff output"
=4E.2 Explain: "RCS file /Repository/module/file.c,v is in use"
=4E.3 I don't want a Vendor branch. Why can't I work on the main trunk?
4E.4 Merges can't work. I don't trust them. If you won't change it to
something I can understand, I won't use CVS.
4E.5 Explain: "co error, line 2: Missing access list"
+4E.6 Explain: "error: RCS file name `xyz .c' contains white space"
+4E.7 Explain: cvs checkout: warning: <X> is not (any longer) pertinent
----------------
-- Section 4G -- Other Systems
----------------
4G.1 I use a NeXT. Is there anything I need to know?
4G.2 I use OS/2. Is there anything I need to know?
4G.3 I use SCO Unix. Is there anything I need to know?
4G.4 I use AIX. Is there anything I need to know?
=4G.5 I use IRIX. Is there anything I need to know?
4G.6 I use an HP system. Is there anything I need to know?
=============================================
== Section 5 ==== Past & Future ====
=============================================
----------------
-- Section 5A -- Contributors
----------------
5A.1 Who wrote CVS?
=5A.2 You didn't write all of this FAQ, did you?
----------------
-- Section 5B -- Bugs and Patches
----------------
5B.1 Why can't CVS handle deletion of directories?
=5B.2 Why can't CVS handle the moving of sources from one place in the
directory hierarchy to another?
=5B.3 Why does "checkout" recurse indefinitely if an alias contains
its own name?
5B.4 When I typed "cvs update -D <date>", why did it check out all
sorts of ancient files from the Attic? Shouldn't it just create
the set of files and revisions that existed at that date?
5B.5 When I typed "cvs update -D <date>" in my branch, why did it
screw up all my files?
5B.6 When I executed "checkout" into an existing directory I got "No
such file or directory" errors. Why?
5B.7 Why does "update" send all output to the terminal after 26 files
have been updated?
+5B.8 Why doesn't the "-I !" option work in update and import?
----------------
-- Section 5C -- Development
----------------
=5C.1 Where do I send bug reports?
=5C.2 Where do I send fixes and patches?
5C.3 Where do I send ideas for future development?
5C.4 What plans are there for fixing bugs?
=5C.5 What plans are there for new features?
=5C.6 I have some time and I'd like to help. What can I do for you?
=================================================
== Section 6 ==== Table of Contents ====
=================================================
% End of Table of Contents
% End of CVS FAQ document
# Local Variables:
# mode: text
# fill-column: 74
# fill-prefix: "\t"
# End:
Reference in New Issue Copy Permalink