DROPBOX EX. 1016
`
`DROPBOX EX. 1016
`
`
`
`

`
`Open Source Development With CVS
`
`Page 1 of 143
`
`Open Source Development with CVS, 3rd Edition
`by Karl Fogel and Moshe Bar
`
`Copyright © 1999, 2000 Karl Fogel <kfogel@red-bean.com>
`
`This document is free software; you can redistribute and/or modify it under the terms of the GNU General Public License as published by the Free
`Software Foundation; either version 2, or (at your option) any later version.
`
`This document is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of
`MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
`
`This manual describes how to use and administer CVS (Concurrent Versions System). It is part of a larger work entitled Open Source Development With
`CVS; please see the introduction for details.
`
`This is version 1.21 of this manual.
`Short Contents
`
`••
`
`Top
`• Introduction
`• An Overview of CVS
`• Repository Administration
`• Advanced CVS
`• Tips And Troubleshooting
`• CVS Reference
`• Third-Party Tools
`• Index
`• GNU General Public License
`• GNU Free Documentation License
`Table of Contents
`
`••
`
`Top
`• Introduction
`• An Overview of CVS
`◦ Basic Concepts
`◦ A Day With CVS
`◾ Conventions Used In This Tour
`◾ Invoking CVS
`◾ Accessing A Repository
`◾ Starting A New Project
`◾ Checking Out A Working Copy
`◾ Version Versus Revision
`◾ Making A Change
`◾ Finding Out What You (And Others) Did - update And diff
`◾ CVS And Implied Arguments
`◾ Committing
`◾ Revision Numbers
`◾ Detecting And Resolving Conflicts
`◾ Finding Out Who Did What (Browsing Log Messages)
`◾ Examining And Reverting Changes
`◾ The Slow Method Of Reverting
`◾ The Fast Method Of Reverting
`◦ Other Useful CVS Commands
`◾ Adding Files
`◾ Adding Directories
`◾ CVS And Binary Files
`◾ Removing Files
`◾ Removing Directories
`
`http://cvsbook.red-bean.com/cvsbook.html
`
`4/1/2016
`
`Dropbox Ex. 1016
`
`

`
`Open Source Development With CVS
`
`Page 2 of 143
`
`◾ Renaming Files And Directories
`◾ Avoiding Option Fatigue
`◾ Getting Snapshots (Dates And Tagging)
`◾ Acceptable Date Formats
`◾ Marking A Moment In Time (Tags)
`◦ Branches
`◾ Branching Basics
`◾ Merging Changes From Branch To Trunk
`◾ Multiple Merges
`◾ Creating A Tag Or Branch Without A Working Copy
`• Repository Administration
`◦ Getting And Installing CVS
`◾ Getting And Building CVS Under Unix
`◾ Getting And Installing CVS Under Windows
`◾ Getting And Installing CVS On A Macintosh
`◾ Limitations Of The Windows And Macintosh Versions
`◦ Anatomy Of A CVS Distribution
`◾ Informational Files
`◾ Subdirectories
`◾ The Cederqvist Manual
`◾ Other Sources Of Information
`◦ Starting A Repository
`◦ The Password-Authenticating Server
`◦ Anonymous Access
`◦ Repository Structure
`◦ RCS Format
`◦ What Happens When You Remove A File
`◦ The CVSROOT/ Administrative Directory
`◾ The config File
`◾ The modules File
`◾ The commitinfo And loginfo And rcsinfo Files
`◾ The verifymsg And rcsinfo Files
`◾ The taginfo File
`◾ The cvswrappers File
`◾ The editinfo File
`◾ The notify File
`◾ The checkoutlist File
`◦ Commit Emails
`◦ Finding Out More
`• Advanced CVS
`◦ Watches (CVS As Telephone)
`◾ How Watches Work
`◾ Enabling Watches In The Repository
`◾ Using Watches In Development
`◾ Ending An Editing Session
`◾ Controlling What Actions Are Watched
`◾ Finding Out Who Is Watching What
`◾ Reminding People To Use Watches
`◾ What Watches Look Like In The Repository
`◦ Log Messages And Commit Emails
`◦ Changing A Log Message After Commit
`◦ Getting Rid Of A Working Copy
`◦ History - A Summary Of Repository Activity
`◦ Annotations - A Detailed View Of Project Activity
`◦ Annotations And Branches
`◦ Using Keyword Expansion
`◦ Going Out On A Limb (How To Work With Branches And Survive)
`◾ Some Principles For Working With Branches
`◾ Merging Repeatedly Into The Trunk
`◾ The Dovetail Approach - Merging In And Out Of The Trunk
`◾ The Flying Fish Approach - A Simpler Way To Do It
`◾ Branches And Keyword Expansion - Natural Enemies
`◦ Tracking Third-Party Sources (Vendor Branches)
`◦ Exporting For Public Distribution
`◦ The Humble Guru
`• Tips And Troubleshooting
`◦ The Usual Suspects
`◾ The Working Copy Administrative Area
`◾ Repository Permissions
`◦ General Troubleshooting Tips
`
`http://cvsbook.red-bean.com/cvsbook.html
`
`4/1/2016
`
`Dropbox Ex. 1016
`
`

`
`Open Source Development With CVS
`
`Page 3 of 143
`
`◦ Some Real Life Problems (With Solutions)
`◾ CVS says it is waiting for a lock; what does that mean?
`◾ CVS claims a file is failing Up-To-Date check; what do I do?
`◾ The pserver access method is not working
`◾ The pserver access method is STILL not working
`◾ My commits seem to happen in pieces instead of atomically
`◾ CVS keeps changing file permissions; why does it do that?
`◾ CVS on Windows complains it cannot find my .cvspass file; why?
`◾ My working copy is on several different branches; help?
`◾ When I do export -d I sometimes miss recent commits
`◾ I get an error about val-tags; what should I do?
`◾ I am having problems with sticky tags; how do I get rid of them?
`◾ Checkouts/updates exit with error saying cannot expand modules
`◾ I cannot seem to turn off watches
`◾ My binary files are messed up
`◾ CVS is not doing line-end conversion correctly
`◾ I need to remove a subdirectory in my project; how do I do it?
`◾ Can I copy .cvspass files or portions of them?
`◾ I just committed some files with the wrong log message
`◾ I need to move files around without losing revision history
`◾ How can I get a list of all tags in a project?
`◾ How can I get a list of all projects in a repository?
`◾ Some commands fail remotely but not locally; how should I debug?
`◾ I do not see my problem covered in this chapter
`◾ I think I have discovered a bug in CVS; what do I do?
`◾ I have implemented a new feature for CVS; to whom do I send it?
`◾ How can I keep up with changes to CVS?
`• CVS Reference
`◦ Commands And Options
`◾ Organization And Conventions
`◾ General Patterns In CVS Commands
`◾ Date Formats
`◾ Global Options
`◾ add
`◾ admin
`◾ annotate
`◾ checkout
`◾ commit
`◾ diff
`◾ edit
`◾ editors
`◾ export
`◾ gserver
`◾ history
`◾ import
`◾ init
`◾ kserver
`◾ log
`◾ login
`◾ logout
`◾ pserver
`◾ rdiff
`◾ release
`◾ remove
`◾ rtag
`◾ server
`◾ status
`◾ tag
`◾ unedit
`◾ update
`◾ watch
`◾ watchers
`◦ Keyword Substitution (RCS Keywords)
`◾ Controlling Keyword Expansion
`◾ List Of Keywords
`◦ Repository Administrative Files
`◾ Storage And Editing
`◾ Shared Syntax
`
`http://cvsbook.red-bean.com/cvsbook.html
`
`4/1/2016
`
`Dropbox Ex. 1016
`
`

`
`Open Source Development With CVS
`
`Page 4 of 143
`
`◾ Shared Variables
`◾ User Variables
`◾ checkoutlist
`◾ commitinfo
`◾ config
`◾ cvsignore
`◾ cvswrappers
`◾ editinfo
`◾ history file
`◾ loginfo
`◾ modules
`◾ notify
`◾ passwd
`◾ rcsinfo
`◾ taginfo
`◾ users
`◾ val-tags
`◾ verifymsg
`◦ Run Control Files
`◾ .cvsrc
`◾ .cvsignore
`◾ .cvspass
`◾ .cvswrappers
`◦ Working Copy Files
`◾ CVS/Base/ (directory)
`◾ CVS/Baserev
`◾ CVS/Baserev.tmp
`◾ CVS/Checkin.prog
`◾ CVS/Entries
`◾ CVS/Entries.Backup
`◾ CVS/Entries.Log
`◾ CVS/Entries.Static
`◾ CVS/Notify
`◾ CVS/Notify.tmp
`◾ CVS/Repository
`◾ CVS/Root
`◾ CVS/Tag
`◾ CVS/Template
`◾ CVS/Update.prog
`◦ Environment Variables
`◾ $COMSPEC
`◾ $CVS_CLIENT_LOG
`◾ $CVS_CLIENT_PORT
`◾ $CVSEDITOR
`◾ $CVSIGNORE
`◾ $CVS_IGNORE_REMOTE_ROOT
`◾ $CVS_PASSFILE
`◾ $CVS_RCMD_PORT
`◾ $CVSREAD
`◾ $CVSROOT
`◾ $CVS_RSH
`◾ $CVS_SERVER
`◾ $CVS_SERVER_SLEEP
`◾ $CVSUMASK
`◾ $CVSWRAPPERS
`◾ $EDITOR
`◾ $HOME %HOMEDRIVE% %HOMEPATH%
`◾ $PATH
`◾ $TEMP $TMP $TMPDIR
`◾ $VISUAL
`• Third-Party Tools
`◦ pcl-cvs - An Emacs Interface To CVS
`◾ Installing pcl-cvs
`◾ Using pcl-cvs
`◾ Error Handling In pcl-cvs
`◾ The Future Of pcl-cvs
`◦ cvsutils - General Utilities For Use With CVS
`◾ cvsu
`
`http://cvsbook.red-bean.com/cvsbook.html
`
`4/1/2016
`
`Dropbox Ex. 1016
`
`

`
`Open Source Development With CVS
`
`Page 5 of 143
`
`◾ cvsdo
`◾ cvschroot
`◾ cvsrmadm
`◾ cvspurge
`◾ cvsdiscard
`◾ cvsco
`◾ cvsdate
`◦ cvs2cl - Generate GNU-Style ChangeLogs
`◦ cvsq - Queue CVS Commands For Later Connection
`◦ cvslock - Lock Repositories For Atomicity
`◦ Other Packages
`◦ Writing Your Own Tools
`• Index
`• GNU General Public License
`• GNU Free Documentation License
`
`Node: Top, Next: Introduction, Up: (dir)
`Top
`
`• Introduction: What is this book?
`• An Overview of CVS: Basic CVS usage -- a tutorial.
`• Repository Administration: How to run a CVS repository.
`• Advanced CVS: What the gurus know.
`• Tips And Troubleshooting: FAQs and real-life experiences.
`• CVS Reference: A reference to CVS commands, variables, etc.
`• Third-Party Tools: Other tools that work with CVS.
`• Index:
`• GNU General Public License:
`• GNU Free Documentation License:
`
`Node: Introduction, Next: An Overview of CVS, Previous: Top, Up: Top
`Introduction
`
`This is a set of free, online chapters about using CVS (Concurrent Versions System) for collaboration and version control. It covers everything from CVS
`installation and basic concepts all the way to advanced usage and administration. It is intended for anyone who uses or plans to use CVS.
`
`These chapters are excerpted from a larger work called Open Source Development With CVS (published by The Coriolis Group, ISBN 1-57610-490-7).
`The remainder of that book - chapters 1, 3, 5, and 7 - deals with the challenges and philosophical issues of running an Open Source project using CVS.
`
`While the free chapters here constitute a complete CVS book by themselves, we certainly hope you'll like them enough to purchase a treeware copy of the
`entire book! You can order it directly from the publisher, at http://www.coriolis.com/bookstore/bookdetail.cfm?id=1576104907.
`
`These chapters are released under the GNU General Public License. For more information about free software in general, visit http://www.gnu.org/, and
`particularly http://www.gnu.org/philosophy/free-sw.html.
`
`To submit comments or errata regarding any of this material, please send email to bug-cvsbook@red-bean.com. For news and updates, visit
`http://cvsbook.red-bean.com/.
`
`Node: An Overview of CVS, Next: Repository Administration, Previous: Introduction, Up: Top
`An Overview of CVS
`
`I can't imagine programming without it... that would be like parachuting without a parachute!
`-Brian Fitzpatrick on CVS
`
`This chapter introduces the fundamentals of CVS, and then provides an in-depth guided tour of everyday CVS usage. Concepts are presented
`sequentially, so if you're new to CVS, the best way to read this is to start at the beginning and go straight through, without skipping anything.
`
`• Basic Concepts: How to think like CVS.
`• A Day With CVS: Guided tour through a sample CVS session.
`• Other Useful CVS Commands: Random useful things.
`• Branches: Splitting development into parallel streams.
`
`Node: Basic Concepts, Next: A Day With CVS, Up: An Overview of CVS
`
`Basic Concepts
`
`http://cvsbook.red-bean.com/cvsbook.html
`
`4/1/2016
`
`Dropbox Ex. 1016
`
`

`
`Open Source Development With CVS
`
`Page 6 of 143
`
`If you've never used CVS (or any version control system) before, it's easy to get tripped up by some of its underlying assumptions. What seems to cause
`the most initial confusion about CVS is that it is used for two apparently unrelated purposes: record keeping and collaboration. It turns out, however, that
`these two functions are closely connected.
`
`Record keeping became necessary because people wanted to compare a program's current state with how it was at some point in the past. For example, in
`the normal course of implementing a new feature, a developer may bring the program into a thoroughly broken state, where it will probably remain until
`the feature is mostly finished. Unfortunately, this is just the time when someone usually calls to report a bug in the last publicly released version. To
`debug the problem (which may also exist in the current version of the sources), the program has to be brought back to a useable state.
`
`Restoring the state poses no difficulty if the source code history is kept under CVS. The developer can simply say, in effect, "Give me the program as it
`was three weeks ago", or perhaps "Give me the program as it was at the time of our last public release". If you've never had this kind of convenient access
`to historical snapshots before, you may be surprised at how quickly you come to depend on it. Personally, I always use revision control on my coding
`projects now - it's saved me many times.
`
`To understand what this has to do with facilitating collaboration, we'll need to take a closer look at the mechanism that CVS provides to help numerous
`people work on the same project. But before we do that, let's take a look at a mechanism that CVS doesn't provide (or at least, doesn't encourage): file
`locking. If you've used other version control systems, you may be familiar with the lock-modify-unlock development model, wherein a developer first
`obtains exclusive write access (a lock) to the file to be edited, makes the changes, and then releases the lock to allow other developers access to the file. If
`someone else already has a lock on the file, they have to "release" it before you can lock it and start making changes (or, in some implementations, you
`may "steal" their lock, but that is often an unpleasant surprise for them and not good practice!).
`
`This system is workable if the developers know each other, know who's planning to do what at any given time, and can communicate with each other
`quickly if someone cannot work because of access contention. However, if the developer group becomes too large or too spread out, dealing with all the
`locking issues begins to chip away at coding time; it becomes a constant hassle that can discourage people from getting real work done.
`
`CVS takes a more mellow approach. Rather than requiring that developers coordinate with each other to avoid conflicts, CVS enables developers to edit
`simultaneously, assumes the burden of integrating all the changes, and keeps track of any conflicts. This process uses the copy-modify-merge model,
`which works as follows:
`
`1. Developer A requests a working copy (a directory tree containing the files that make up the project) from CVS. This is also known as "checking
`out" a working copy, like checking a book out of the library.
`2. Developer A edits freely in her working copy. At the same time, other developers may be busy in their own working copies. Because these are all
`separate copies, there is no interference - it is as though all of the developers have their own copy of the same library book, and they're all at work
`scribbling comments in the margins or rewriting certain pages independently.
`3. Developer A finishes her changes and commits them into CVS along with a "log message", which is a comment explaining the nature and purpose
`of the changes. This is like informing the library of what changes she made to the book and why. The library then incorporates these changes into a
`"master" copy, where they are recorded for all time.
`4. Meanwhile, other developers can have CVS query the library to see if the master copy has changed recently. If it has, CVS automatically updates
`their working copies. (This part is magical and wonderful, and I hope you appreciate it. Imagine how different the world would be if real books
`worked this way!)
`
`As far as CVS is concerned, all developers on a project are equal. Deciding when to update or when to commit is largely a matter of personal preference
`or project policy. One common strategy for coding projects is to always update before commencing work on a major change and to commit only when
`the changes are complete and tested so that the master copy is always in a "runnable" state.
`
`Perhaps you're wondering what happens when developers A and B, each in their own working copy, make different changes to the same area of text and
`then both commit their changes? This is called a conflict, and CVS notices it as soon as developer B tries to commit changes. Instead of allowing
`developer B to proceed, CVS announces that it has discovered a conflict and places conflict markers (easily recognizable textual flags) at the conflicting
`location in his copy. That location also shows both sets of changes, arranged for easy comparison. Developer B must sort it all out and commit a new
`revision with the conflict resolved. Perhaps the two developers will need to talk to each other to settle the issue. CVS only alerts the developers that there
`is a conflict; it's up to human beings to actually resolve it.
`
`What about the master copy? In official CVS terminology, it is called the project's repository. The repository is simply a file tree kept on a central server.
`Without going into too much detail about its structure (but see Repository Administration), let's look at what the repository must do to meet the
`requirements of the checkout-commit-update cycle. Consider the following scenario:
`
`1. Two developers, A and B, check out working copies of a project at the same time. The project is at its starting point - no changes have been
`committed by anyone yet, so all the files are in their original, pristine state.
`2. Developer A gets right to work and soon commits her first batch of changes.
`3. Meanwhile, developer B watches television.
`4. Developer A, hacking away like there's no tomorrow, commits her second batch of changes. Now, the repository's history contains the original
`files, followed by A's first batch of changes, followed by this set of changes.
`5. Meanwhile, developer B plays video games.
`6. Suddenly, developer C joins the project and checks out a working copy from the repository. Developer C's copy reflects A's first two sets of
`changes, because they were already in the repository when C checked out her copy.
`7. Developer A, continuing to code as one possessed by spirits, completes and commits her third batch of changes.
`8. Finally, blissfully unaware of the recent frenzy of activity, developer B decides it's time to start work. He doesn't bother to update his copy; he just
`commences editing files, some of which may be files that A has worked in. Shortly thereafter, developer B commits his first changes.
`
`At this point, one of two things can happen. If none of the files edited by developer B have been edited by A, the commit succeeds. However, if CVS
`realizes that some of B's files are out of date with respect to the repository's latest copies, and those files have also been changed by B in his working
`copy, CVS informs B that he must do an update before committing those files.
`
`http://cvsbook.red-bean.com/cvsbook.html
`
`4/1/2016
`
`Dropbox Ex. 1016
`
`

`
`Open Source Development With CVS
`
`Page 7 of 143
`
`When developer B runs the update, CVS merges all of A's changes into B's local copies of the files. Some of A's work may conflict with B's uncommitted
`changes, and some may not. Those parts that don't are simply applied to B's copies without further complication, but the conflicting changes must be
`resolved by B before being committed.
`
`If developer C does an update now, she'll receive various new changes from the repository: those from A's third commit, and those from B's first
`successful commit (which might really come from B's second attempt to commit, assuming B's first attempt resulted in B being forced to resolve
`conflicts).
`
`In order for CVS to serve up changes, in the correct sequence, to developers whose working copies may be out of sync by varying degrees, the repository
`needs to store all commits since the project's beginning. In practice, the CVS repository stores them all as successive diffs. Thus, even for a very old
`working copy, CVS is able to calculate the difference between the working copy's files and the current state of the repository, and is thereby able to bring
`the working copy up to date efficiently. This makes it easy for developers to view the project's history at any point and to revive even very old working
`copies.
`
`Although, strictly speaking, the repository could achieve the same results by other means, in practice, storing diffs is a simple, intuitive means of
`implementing the necessary functionality. The process has the added benefit that, by using patch appropriately, CVS can reconstruct any previous state of
`the file tree and thus bring any working copy from one state to another. It can allow someone to check out the project as it looked at any particular time. It
`can also show the differences, in diff format, between two states of the tree without affecting someone's working copy.
`
`Thus, the very features necessary to give convenient access to a project's history are also useful for providing a decentralized, uncoordinated developer
`team with the ability to collaborate on the project.
`
`For now, you can ignore the details of setting up a repository, administering user access, and navigating CVS-specific file formats (those will be covered
`in Repository Administration). For the moment, we'll concentrate on how to make changes in a working copy.
`
`But first, here is a quick review of terms:
`
`• Revision A committed change in the history of a file or set of files. A revision is one "snapshot" in a constantly changing project.
`• Repository The master copy where CVS stores a project's full revision history. Each project has exactly one repository.
`• Working copy The copy in which you actually make changes to a project. There can be many working copies of a given project; generally each
`developer has his or her own copy.
`• Check out To request a working copy from the repository. Your working copy reflects the state of the project as of the moment you checked it out;
`when you and other developers make changes, you must use commit and update to "publish" your changes and view others' changes.
`• Commit To send changes from your working copy into the central repository. Also known as check-in.
`• Log message A comment you attach to a revision when you commit it, describing the changes. Others can page through the log messages to get a
`summary of what's been going on in a project.
`• Update To bring others' changes from the repository into your working copy and to show if your working copy has any uncommitted changes. Be
`careful not to confuse this with commit; they are complementary operations. Mnemonic: update brings your working copy up to date with the
`repository copy.
`• Conflict The situation when two developers try to commit changes to the same region of the same file. CVS notices and points out conflicts, but the
`developers must resolve them.
`
`Node: A Day With CVS, Next: Other Useful CVS Commands, Previous: Basic Concepts, Up: An Overview of CVS
`
`A Day With CVS
`
`This section describes some basic CVS operations, then follows with a sample session covering typical CVS usage. As the guided tour progresses, we'll
`also start to look at how CVS works internally.
`
`Although you don't need to understand every last detail of CVS's implementation to use it, a basic knowledge of how it works is invaluable in choosing
`the best way to achieve a given result. CVS is more like a bicycle than an automobile, in the sense that its mechanisms are entirely transparent to anyone
`who cares to look. As with a bicycle, you can just hop on and start riding immediately. However, if you take a few moments to study how the gears work,
`you'll be able to ride it much more efficiently. (In the case of CVS, I'm not sure whether transparency was a deliberate design decision or an accident, but
`it does seem to be a property shared by many free programs. Externally visible implementations have the advantage of encouraging the users to become
`contributing developers by exposing them to the system's inner workings right from the start.)
`
`Each part of the tour may make use of knowledge introduced in previous parts. Therefore, if this is your first time, I recommend that you simply start at
`the beginning and take the tour sequentially, without skipping over anything. The menu below is merely meant as a convenience for repeat visitors - you
`shouldn't use it to jump directly to a section that interests you unless you're already familiar with the material in the previous sections.
`
`• Conventions Used In This Tour:
`• Invoking CVS:
`• Accessing A Repository:
`• Starting A New Project:
`• Checking Out A Working Copy:
`• Version Versus Revision:
`• Making A Change:
`• Finding Out What You (And Others) Did -- update And diff:
`• CVS And Implied Arguments:
`• Committing:
`• Revision Numbers:
`• Detecting And Resolving Conflicts:
`• Finding Out Who Did What (Browsing Log Messages):
`• Examining And Reverting Changes:
`
`http://cvsbook.red-bean.com/cvsbook.html
`
`4/1/2016
`
`Dropbox Ex. 1016
`
`

`
`Open Source Development With CVS
`
`Page 8 of 143
`
`• The Slow Method Of Reverting:
`• The Fast Method Of Reverting:
`
`Node: Conventions Used In This Tour, Next: Invoking CVS, Up: A Day With CVS
`
`Conventions Used In This Tour
`
`The tour takes place in a Unix environment. CVS also runs on Windows and Macintosh operating systems, and Tim Endres of Ice Engineering has even
`written a Java client (see http://www.trustice.com/java/jcvs/), which can be run anywhere Java runs. However, I'm going to take a wild guess and assume
`that the majority of CVS users - present and potential - are most likely working in a Unix command-line environment. If you aren't one of these, the
`examples in the tour should be easy to translate to other interfaces. Once you understand the concepts, you can sit down at any CVS front end and work
`with it (trust me, I've done it many times).
`
`The examples in the tour are oriented toward people who will be using CVS to keep track of programming projects. However, CVS operations are
`applicable to all text documents, not just source code.
`
`The tour also assumes that you already have CVS installed (it's present by default on many of the popular free Unix systems, so you might already have it
`without knowing it) and that you have access to a repository. Even if you are not set up, you can still benefit from reading the tour. In Repository
`Administration, you'll learn how to install CVS and set up repositories.
`
`Assuming CVS is installed, you should take a moment to find the online CVS manual. Known familiarly as the "Cederqvist" (after Per Cederqvist, its
`original author), it comes with the CVS source distribution and is usually the most up-to-date reference available. It's written in Texinfo format and
`should be available on Unix systems in the "Info" documentation hierarchy. You can read it either with the command line info program
` floss$ info cvs
`
`or by pressing Ctrl+H and then typing "i" inside Emacs. If neither of these works for you, consult your local Unix guru (or see Repository Administration
`regarding installation issues). You'll definitely want to have the Cederqvist at your fingertips if you're going to be using CVS regularly.
`
`Node: Invoking CVS, Next: Accessing A Repository, Previous: Conventions Used In This Tour, Up: A Day With CVS
`
`Invoking CVS
`
`CVS is one program, but it can perform many different actions: updating, committing, branching, diffing, and so on. When you invoke CVS, you must
`specify which action you want to perform. Thus, the format of a CVS invocation is:
` floss$ cvs command
`
`For example, you can use
` floss$ cvs update
` floss$ cvs diff
` floss$ cvs commit
`
`and so on. (Don't bother to try running any of those particular commands yet, though; they won't do anything until you're in a working copy, which we'll
`get to shortly.)
`
`Both CVS and the command can take options. Options that affect the behavior of CVS, independently of the command being run, are called global
`options; command-specific options are just called command options. Global options always go to the left of the command; command options, to its right.
`So in
` floss$ cvs -Q update -p
`
`-Q is a global option, and -p is a command option. (If you're curious, -Q means "quietly"-that is, suppress all diagnostic output, and print error messages
`only if the command absolutely cannot be completed for some reason; -p means to send the results of update to standard output instead of to files.)
`
`Node: Accessing A Repository, Next: Starting A New Project, Previous: Invoking CVS, Up: A Day With CVS
`
`Accessing A Repository
`
`Before you can do anything, you must tell CVS the location of the repository you'll be accessing. This isn't a concern if you already have a working copy
`checked out - any working copy knows what repository it came from, so CVS can automatically deduce the repository for a given working copy.
`However, let's assume you don't have a working copy yet, so you need to tell CVS explicitly where to go. This is done with the -d global option (the -d
`stands for "directory", an abbreviation for which there is a historical justification, although -r for "repository" might have been better), followed by the
`path to the repository. For example, assuming the repository is on the local machine in /usr/local/cvs (a fairly standard location):
` floss$ cvs -d /usr/local/cvs command
`
`In many cases, however, the repository is on another machine and must therefore be reached over the network. CVS provides a choice of network access
`methods; which one you'll use depends mostly on the security needs of the repository machine (hereinafter referred to as "the server"). Setting up the
`server to allow various remote access methods is covered in Repository Administration; here we'll deal only with the client side.
`
`http://cvsbook.red-bean.com/cvsbook.html
`
`4/1/2016
`
`Dropbox Ex. 1016
`
`

`
`Open Source Development With CVS
`
`Page 9 of 143
`
`Fortunately, all the remote access methods share a common invocation syntax. In general, to specify a remote repository as opposed to a local one, you
`just use a longer repository path. You first name the access method, delimited on each side by colons, followed by the username and the server name
`(joined with an @ sign), another separator colon, and finally the path to the repository directory on the server.
`
`Let's look at the pserver access method, which stands for "password-authenticated server":
` floss$ cvs -d :pserver:jrandom@cvs.foobar.com:/usr/local/cvs login
` (Logging in to jrandom@cvs.foobar.com)
` CVS password: (enter your CVS password here)
` floss$
`
`The long repository path following -d told CVS to use the pserver access method, with the username jrandom, on the server cvs.foobar.com, which has a
`CVS repository in /usr/local/cvs. There's no requirement that the hostname be "cvs.something.com" by the way; that's a common convention, but it could
`just as easily have been:
` floss$ cvs -d :pserver:jrandom@fish.foobar.org:/usr/local/cvs command
`
`The command actually run was login, which verifies that you are authorized to work with this repository. It prompts for a password, then contacts the
`server to verify the password. Following Unix custom, cvs login returns silently if the login succeeds; it shows an error message if it fails (for instance,
`because the password is incorrect).
`
`You only have to log in once from your local machine to a given CVS server. After a successful login, CVS stores the password in your home directory,
`in a file called .cvspass. It consults that file every time a repository is contacted via the pserver method, so you only have to run login the first time you
`access a given CVS server from a particular client machine. Of course, you can rerun cvs login anytime if the password changes.
`
`Note: pserver is currently the only access method requiring an initial login like this; with the others, you can start running regular CVS commands
`immediately.
`
`Once you've stored the authentication information in your .cvspass file, you can run other CVS commands using the same command-line syntax:
` floss$ cvs -d :pserver:jrandom@cvs.foobar.com:/usr/local/cvs command
`
`Getting pserver to work in Windows may require an extra step. Windows doesn't have the Unix concept of a home directory, so CVS doesn't know where
`to put the .cvspass file. You'll have to specify a location. It's normal to designate the root of the C: drive as the home directory:
` C:\WINDOWS> set HOME=C:
` C:\WINDOWS> cvs -d :pserver:jrandom@cvs.foobar.com:/usr/local/cvs login
` (Logging in to jrandom@cvs.foobar.com)
` CVS password: (enter password here)
` C:\WINDOWS>
`
`Any folder in the file system will suffice. You may want to avoid network drives, though, because the contents of your .cvspass file would then be visible
`to anyone with access to the drive.
`
`In addition to pserver, CVS supports the ext method (which uses an external connection program, such as rsh or ssh), kserver (for the Kerberos security
`system version 4), and gserver (which uses the GSSAPI, or Generic Security Services API, and also handles Kerberos versions 5 and higher). These
`methods are similar to pserver, but each has