第1页 / 共184页
第2页 / 共184页
第3页 / 共184页
第4页 / 共184页
第5页 / 共184页
第6页 / 共184页
第7页 / 共184页
第8页 / 共184页
cvs版本控制原理-version management with cvs.pdf
Overview
What is CVS?
What is CVS not?
A sample session
Getting the source
Committing your changes
Cleaning up
Viewing differences
The Repository
Telling CVS where your repository is
How data is stored in the repository
Where files are stored within the repository
File permissions
File Permission issues specific to Windows
The attic
The CVS directory in the repository
CVS locks in the repository
How files are stored in the CVSROOT directory
How data is stored in the working directory
The administrative files
Editing administrative files
Multiple repositories
Creating a repository
Backing up a repository
Moving a repository
Remote repositories
Server requirements
Connecting with rsh
Direct connection with password authentication
Setting up the server for password authentication
Using the client with password authentication
Security considerations with password authentication
Direct connection with GSSAPI
Direct connection with kerberos
Connecting with fork
Read-only repository access
Temporary directories for the server
Starting a project with CVS
Setting up the files
Creating a directory tree from a number of files
Creating Files From Other Version Control Systems
Creating a directory tree from scratch
Defining the module
Revisions
Revision numbers
Versions, revisions and releases
Assigning revisions
Tags--Symbolic revisions
Specifying what to tag from the working directory
Specifying what to tag by date or revision
Deleting, moving, and renaming tags
Tagging and adding and removing files
Sticky tags
Branching and merging
What branches are good for
Creating a branch
Accessing branches
Branches and revisions
Magic branch numbers
Merging an entire branch
Merging from a branch several times
Merging differences between any two revisions
Merging can add or remove files
Merging and keywords
Recursive behavior
Adding, removing, and renaming files and directories
Adding files to a directory
Removing files
Removing directories
Moving and renaming files
The Normal way to Rename
Moving the history file
Copying the history file
Moving and renaming directories
History browsing
Log messages
The history database
User-defined logging
Annotate command
Handling binary files
The issues with binary files
How to store binary files
Multiple developers
File status
Bringing a file up to date
Conflicts example
Informing others about commits
Several developers simultaneously attempting to run CVS
Mechanisms to track who is editing files
Telling CVS to watch certain files
Telling CVS to notify you
How to edit a file which is being watched
Information about who is watching and editing
Using watches with old versions of CVS
Choosing between reserved or unreserved checkouts
Revision management
When to commit?
Keyword substitution
Keyword List
Using keywords
Avoiding substitution
Substitution modes
Problems with the $Log$ keyword.
Tracking third-party sources
Importing for the first time
Updating with the import command
Reverting to the latest vendor release
How to handle binary files with cvs import
How to handle keyword substitution with cvs import
Multiple vendor branches
How your build system interacts with CVS
Special Files
Guide to CVS commands
Overall structure of CVS commands
CVS's exit status
Default options and the {@char 126}/.cvsrc file
Global options
Common command options
admin---Administration
admin options
checkout---Check out sources for editing
checkout options
checkout examples
commit---Check files into the repository
commit options
commit examples
Committing to a branch
Creating the branch after editing
diff---Show differences between revisions
diff options
Line group formats
Line formats
diff examples
export---Export sources from CVS, similar to checkout
export options
history---Show status of files and users
history options
import---Import sources into CVS, using vendor branches
import options
import output
import examples
log---Print out log information for files
log options
log examples
rdiff---'patch' format diffs between releases
rdiff options
rdiff examples
release---Indicate that a Module is no longer in use
release options
release output
release examples
update---Bring work tree in sync with repository
update options
update output
Quick reference to CVS commands
Reference manual for Administrative files
The modules file
Alias modules
Regular modules
Ampersand modules
Excluding directories
Module options
How the modules file ``program options'' programs are run
The cvswrappers file
The commit support files
The common syntax
Commitinfo
Verifying log messages
Editinfo
Editinfo example
Loginfo
Loginfo example
Keeping a checked out copy
Rcsinfo
Ignoring files via cvsignore
The checkoutlist file
The history file
Expansions in administrative files
The CVSROOT/config configuration file
All environment variables which affect CVS
Compatibility between CVS Versions
Troubleshooting
Partial list of error messages
Trouble making a connection to a CVS server
Other common problems
Credits
Dealing with bugs in CVS or this manual
Index
Version Management
with
CVS
for cvs 1.11.2
Per Cederqvist et al
Copyright c 1992, 1993 Signum Support AB
Permission is granted to make and distribute verbatim copies of this manual provided the
copyright notice and this permission notice are preserved on all copies.
Permission is granted to copy and distribute modified versions of this manual under the
conditions for verbatim copying, provided also that the entire resulting derived work is
distributed under the terms of a permission notice identical to this one.
Permission is granted to copy and distribute translations of this manual into another lan-
guage, under the above conditions for modified versions, except that this permission notice
may be stated in a translation approved by the Free Software Foundation.
Chapter 1: Overview
1 Overview
1
This chapter is for people who have never used cvs, and perhaps have never used version
control software before.
If you are already familiar with cvs and are just trying to learn a particular feature or
remember a certain command, you can probably skip everything here.
1.1 What is CVS?
cvs is a version control system. Using it, you can record the history of your source files.
For example, bugs sometimes creep in when software is modified, and you might not
detect the bug until a long time after you make the modification. With cvs, you can easily
retrieve old versions to see exactly which change caused the bug. This can sometimes be a
big help.
You could of course save every version of every file you have ever created. This would
however waste an enormous amount of disk space. cvs stores all the versions of a file in a
single file in a clever way that only stores the differences between versions.
cvs also helps you if you are part of a group of people working on the same project.
It is all too easy to overwrite each others’ changes unless you are extremely careful. Some
editors, like gnu Emacs, try to make sure that the same file is never modified by two people
at the same time. Unfortunately, if someone is using another editor, that safeguard will
not work. cvs solves this problem by insulating the different developers from each other.
Every developer works in his own directory, and cvs merges the work when each developer
is done.
cvs started out as a bunch of shell scripts written by Dick Grune, posted to the news-
group comp.sources.unix in the volume 6 release of December, 1986. While no actual code
from these shell scripts is present in the current version of cvs much of the cvs conflict
resolution algorithms come from them.
In April, 1989, Brian Berliner designed and coded cvs. Jeff Polk later helped Brian with
the design of the cvs module and vendor branch support.
You can get cvs in a variety of ways, including free download from the internet. For
more information on downloading cvs and other cvs topics, see:
http://www.cvshome.org/
http://www.loria.fr/~molli/cvs-index.html
There is a mailing list, known as info-cvs, devoted to cvs. To subscribe or
If you prefer a usenet group, the
unsubscribe write to info-cvs-request@gnu.org.
right group is comp.software.config-mgmt which is for cvs discussions (along with
other configuration management systems). In the future, it might be possible to create a
comp.software.config-mgmt.cvs, but probably only if there is sufficient cvs traffic on
comp.software.config-mgmt.
You can also subscribe to the bug-cvs mailing list, described in more detail in Appendix H
[BUGS], page 165. To subscribe send mail to bug-cvs-request@gnu.org.
2
CVS—Concurrent Versions System v1.11.2
1.2 What is CVS not?
cvs can do a lot of things for you, but it does not try to be everything for everyone.
cvs is not a build system.
Though the structure of your repository and modules file interact with your
build system (e.g. ‘Makefile’s), 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 directo-
ries. If you write your ‘Makefile’s 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.
If you modularize your work, and construct a build system that will share files
(via links, mounts, VPATH in ‘Makefile’s, 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.
Of course, you should place the tools created to support such a build system
(scripts, ‘Makefile’s, etc) under cvs.
Figuring out what files need to be rebuilt when something changes is, again,
something to be handled outside the scope of cvs. One traditional approach
is to use make for building, and use some automated tool for generating the
dependencies which make uses.
See Chapter 14 [Builds], page 83, for more information on doing builds in
conjunction with 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 re-
solve them without too much effort. But a more general definition of “conflict”
includes problems too difficult to solve without communication between devel-
opers.
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.
Chapter 1: Overview
3
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 does not have change control
Change control refers to a number of things. First of all it can mean bug-
tracking, that is being able to keep a database of reported bugs and the sta-
tus of each one (is it fixed? in what release? has the bug submitter agreed
that it is fixed?). For interfacing cvs to an external bug-tracking system, see
the ‘rcsinfo’ and ‘verifymsg’ files (see Appendix C [Administrative files],
page 135).
Another aspect of change control is keeping track of the fact that changes to
several files were in fact changed together as one logical change. If you check in
several files in a single cvs commit operation, cvs then forgets that those files
were checked in together, and the fact that they have the same log message is
the only thing tying them together. Keeping a gnu style ‘ChangeLog’ can help
somewhat.
Another aspect of change control, in some systems, is the ability to keep track
of the status of each change. Some changes have been written by a developer,
others have been reviewed by a second developer, and so on. Generally, the way
to do this with cvs is to generate a diff (using cvs diff or diff) and email it
to someone who can then apply it using the patch utility. This is very flexible,
but depends on mechanisms outside cvs to make sure nothing falls through the
cracks.
cvs is not an automated testing program
It should be possible to enforce mandatory use of a testsuite using the
commitinfo file.
I haven’t heard a lot about projects trying to do that or
whether there are subtle gotchas, however.
cvs does not have a builtin process model
Some systems provide ways to ensure that changes or releases go through various
steps, with various approvals as needed. Generally, one can accomplish this
with cvs but it might be a little more work.
In some cases you’ll want to
use the ‘commitinfo’, ‘loginfo’, ‘rcsinfo’, or ‘verifymsg’ files, to require
that certain steps be performed before cvs will allow a checkin. Also consider
whether features such as branches and tags can be used to perform tasks such
as doing work in a development tree and then merging certain changes over to
a stable tree only once they have been proven.
1.3 A sample session
As a way of introducing cvs, we’ll go through a typical work-session using cvs. The first
thing to understand is that cvs stores all files in a centralized repository (see Chapter 2
[Repository], page 7); this section assumes that a repository is set up.
4
CVS—Concurrent Versions System v1.11.2
Suppose you are working on a simple compiler. The source consists of a handful of C
files and a ‘Makefile’. The compiler is called ‘tc’ (Trivial Compiler), and the repository is
set up so that there is a module called ‘tc’.
1.3.1 Getting the source
The first thing you must do is to get your own working copy of the source for ‘tc’. For
this, you use the checkout command:
$ cvs checkout tc
This will create a new directory called ‘tc’ and populate it with the source files.
$ cd tc
$ ls
CVS
Makefile
backend.c
driver.c
frontend.c
parser.c
The ‘CVS’ directory is used internally by cvs. Normally, you should not modify or remove
any of the files in it.
You start your favorite editor, hack away at ‘backend.c’, and a couple of hours later
you have added an optimization pass to the compiler. A note to rcs and sccs users: There
is no need to lock the files that you want to edit. See Chapter 10 [Multiple developers],
page 63, for an explanation.
1.3.2 Committing your changes
When you have checked that the compiler is still compilable you decide to make a new
version of ‘backend.c’. This will store your new ‘backend.c’ in the repository and make it
available to anyone else who is using that same repository.
$ cvs commit backend.c
cvs starts an editor, to allow you to enter a log message. You type in “Added an optimiza-
tion pass.”, save the temporary file, and exit the editor.
The environment variable $CVSEDITOR determines which editor is started. If $CVSEDITOR
is not set, then if the environment variable $EDITOR is set,
If both
$CVSEDITOR and $EDITOR are not set then there is a default which will vary with your
operating system, for example vi for unix or notepad for Windows NT/95.
it will be used.
In addition, cvs checks the $VISUAL environment variable. Opinions vary on whether
this behavior is desirable and whether future releases of cvs should check $VISUAL or ignore
it. You will be OK either way if you make sure that $VISUAL is either unset or set to the
same thing as $EDITOR.
When cvs starts the editor, it includes a list of files which are modified. For the cvs
client, this list is based on comparing the modification time of the file against the mod-
ification time that the file had when it was last gotten or updated. Therefore, if a file’s
modification time has changed but its contents have not, it will show up as modified. The
simplest way to handle this is simply not to worry about it—if you proceed with the commit
cvs will detect that the contents are not modified and treat it as an unmodified file. The
next update will clue cvs in to the fact that the file is unmodified, and it will reset its
stored timestamp so that the file will not show up in future editor sessions.
If you want to avoid starting an editor you can specify the log message on the command
line using the ‘-m’ flag instead, like this:
Chapter 1: Overview
5
$ cvs commit -m "Added an optimization pass" backend.c
1.3.3 Cleaning up
Before you turn to other tasks you decide to remove your working copy of tc. One
acceptable way to do that is of course
$ cd ..
$ rm -r tc
but a better way is to use the release command (see Section A.15 [release], page 118):
$ cd ..
$ cvs release -d tc
M driver.c
? tc
You have [1] altered files in this repository.
Are you sure you want to release (and delete) directory ‘tc’: n
** ‘release’ aborted by user choice.
The release command checks that all your modifications have been committed.
If
history logging is enabled it also makes a note in the history file. See Section C.7 [history
file], page 147.
When you use the ‘-d’ flag with release, it also removes your working copy.
In the example above, the release command wrote a couple of lines of output. ‘? tc’
means that the file ‘tc’ is unknown to cvs. That is nothing to worry about: ‘tc’ is the exe-
cutable compiler, and it should not be stored in the repository. See Section C.5 [cvsignore],
page 145, for information about how to make that warning go away. See Section A.15.2
[release output], page 118, for a complete explanation of all possible output from release.
‘M driver.c’ is more serious. It means that the file ‘driver.c’ has been modified since
it was checked out.
The release command always finishes by telling you how many modified files you have
in your working copy of the sources, and then asks you for confirmation before deleting any
files or making any note in the history file.
You decide to play it safe and answer n hRETi when release asks for confirmation.
1.3.4 Viewing differences
You do not remember modifying ‘driver.c’, so you want to see what has happened to
that file.
$ cd tc
$ cvs diff driver.c
This command runs diff to compare the version of ‘driver.c’ that you checked out with
your working copy. When you see the output you remember that you added a command
line option that enabled the optimization pass. You check it in, and release the module.
$ cvs commit -m "Added an optimization pass" driver.c
Checking in driver.c;
/usr/local/cvsroot/tc/driver.c,v
new revision: 1.2; previous revision: 1.1
driver.c
<--
6
CVS—Concurrent Versions System v1.11.2
done
$ cd ..
$ cvs release -d tc
? tc
You have [0] altered files in this repository.
Are you sure you want to release (and delete) directory ‘tc’: y
相关推荐
2023年江西萍乡中考道德与法治真题及答案.doc
2012年重庆南川中考生物真题及答案.doc
2013年江西师范大学地理学综合及文艺理论基础考研真题.doc
2020年四川甘孜小升初语文真题及答案I卷.doc
2020年注册岩土工程师专业基础考试真题及答案.doc
2023-2024学年福建省厦门市九年级上学期数学月考试题及答案.doc
2021-2022学年辽宁省沈阳市大东区九年级上学期语文期末试题及答案.doc
2022-2023学年北京东城区初三第一学期物理期末试卷及答案.doc
2018上半年江西教师资格初中地理学科知识与教学能力真题及答案.doc
2012年河北国家公务员申论考试真题及答案-省级.doc
2020-2021学年江苏省扬州市江都区邵樊片九年级上学期数学第一次质量检测试题及答案.doc
2022下半年黑龙江教师资格证中学综合素质真题及答案.doc
