Table of Contents
When more than one person works on a software project things often get complicated. Often, two people try to edit the same file simultaneously. One solution, known as file locking or reserved checkouts, is to allow only one person to edit each file at a time. This is the only solution with some version control systems, including rcs, sccs, visual studio, pvcs etc. Currently the usual way to get reserved checkouts with cvsnt is the setting the file to have the cvsnt expansion keyword -kx or -kc (the section called “Substitution modes”) and using the command cvs edit (???). This is very nicely integrated into cvsnt and can work with the watch features, described below.
The default model with cvsnt is known as unreserved checkouts. In this model, developers can edit their own working copy of a file simultaneously. The first person that commits his changes has no automatic way of knowing that another has started to edit it. Others will get an error message when they try to commit the file. They must then use cvsnt commands to bring their working copy up to date with the repository revision. This process is almost automatic.
cvsnt also supports mechanisms which facilitate various kinds of communication, without actually enforcing rules like reserved checkouts do.
The rest of this chapter describes how these various models work, and some of the issues involved in choosing between them.
Based on what operations you have performed on a checked out file, and what operations others have performed to that file in the repository, one can classify a file in a number of states. The states, as reported by the status command, are:
The file is identical with the latest revision in the repository for the branch in use.
This is like Locally Modified, except that a previous update command gave a conflict. If you have not already done so, you need to resolve the conflict as described in the section called “Conflicts example”.
To help clarify the file status, status also reports the Working revision which is the revision that the file in the working directory derives from, and the Repository revision which is the latest revision in the repository for the branch in use.
The options to status are listed in the section called “status--Display the state of a file in the working directory”. For information on its Sticky tag and Sticky date output, see the section called “Sticky tags”. For information on its Sticky options output, see the -k option in the section called “update options”.
You can think of the status and update commands as somewhat complementary. You use update to bring your files up to date, and you can use status to give you some idea of what an update would do (of course, the state of the repository might change before you actually run update). In fact, if you want a command to display file status in a more brief format than is displayed by the status command, you can invoke
$ cvs -n -q update
The -n option means to not actually do the update, but merely to display statuses; the -q option avoids printing the name of each directory. For more information on the update command, and these options, see the section called “update--Bring work tree in sync with repository”.