If you're concerned about this issue, the VC source code (vc.el in your Emacs Lisp source directory) includes a comment giving a careful and extensive analysis of potential multiuser conflict and race situations. VC is exactly as safe from them as the underlying utilities can be.
12.9 Customizing VC
Some of the rules we've described earlier in the chapter for VC's behavior can be changed by setting certain Emacs variables related to VC mode. We'll go over a few of the most important here.
vc-handled-backends
This variable controls the set of version control systems used by VC, and the order in which they are found in the list controls the order in which they are attempted. It defaults to (RCS CVS SVN MCVS SCCS). If you remove values from the list, they won't be considered valid version control systems to use. If the list is empty, VC is disabled entirely.
vc-display-status
This variable displays a file's revision number and status on the mode line of each buffer visiting it, if this is non-nil. To avoid expensive queries of the master file, you may want to turn this variable off if you are running VC over very slow network links.
vc-backend-header
These variables provides lists of the headers to be inserted by vc-insert-headers when using the specified version control system. For example, the headers for CVS are in the variable vc-cvs-header. You can customize these lists if you like a different format for your version number headers.
vc-keep-workfiles
Normally, VC leaves a read-only copy of the work file in place whenever it performs a check-in. This feature is convenient because it means make and other tools always find work files where they expect to. If you're very tight on disk space, you can turn it off, but then you have to execute an explicit check-out every time a tool other than VC needs the work file. (Emacs itself knows about version control through a piece of VC code that's always resident; its visit commands perform a check-out if necessary, without locking the file.)
vc-mistrust-permissions
This variable is normally nil. Make it t to tell VC not to trust a file's permissions or ownership as indicators of its version control state. This change slows VC down a lot, but it may be necessary if (for example) your development group is working in several different directories and accessing work files via symbolic links. In such a case, the permissions and ownership of the link convey nothing about the state of the work file.
vc-suppress-confirm
This variable defaults to nil. If it is non-nil, it suppresses the confirmation prompt vc-revert-buffer normally gives you before discarding changes.
vc-initial-comment
Most version control systems allow (but do not require) you to enter an initial comment when you register a file—a lead-off for the change history. If this variable is non-nil, VC pops up a buffer for this comment at registration time just as it normally does for change comments at check-in time.
diff-switches
The Emacs diff.el mode takes command-line switches from this global variable to pass to diff when generating a change report. VC uses it the same way. It defaults to the single switch -c to force context-diff format; -u for unified-diff format is also fairly popular.
A number of other, less important global variables are fully documented in the Emacs online help system.
12.10 Extending VC
VC was designed from the beginning to be usable as a front-end for multiple version control systems. The code that actually runs the version control tools is carefully isolated from the user-level package logic in such a way that plugging in new systems is not very hard. VC's author originally wrote it to handle SCCS and RCS; CVS support was added later, by a different person, without much difficulty, and Subversion support was an even simpler variant of the CVS code.
There are a couple of extensions to Emacs for users of ClearCase, a popular commercial project-management system. Whether this code is accepted into the GNU Emacs distribution, considering the FSF's hostile attitude towards non-freeware, is another question. So far they have not been, but you can obtain the packages over the internet. At the time of this writing, the best choice appears to be clearcase.el. The author of the first implementation, VC-ClearCase, has even stated that he's switched over to clearcase.el. The current download site is http://members.verizon.net/~vze24fr2/EmacsClearCase/. If it's moved by the time you read this, hopefully a Google search will steer you in the right direction.
By the time you read this book, then, your VC may well handle additional systems besides the ones we have described here (though CVS and Subversion are likely to remain the most popular ones for the foreseeable future). If you are a skilled Emacs Lisp programmer (or would like to become one) and have your own favorite version control system, by all means hack the source code—extend VC to use it, and share your results so that everyone benefits.
12.11 What VC Is Not
VC is not a total solution to the project-management problem. Although it assists single-author programming or document maintenance greatly and can give vital help on small- to medium-scale projects involving several developers, it's not necessarily adequate by itself for large multiple-component, multiple-directory projects. The following are some of its more obvious deficiencies for larger projects:
• It is not integrated with a change request or problem-report system.
• Its only way of grouping project files is by directory subtree. This limitation may create problems for large, multiple-directory projects, especially when two or more need to share a common library or subtree.
You can work around these deficiencies on small projects. Variant versions might be handled with compile-time conditions, like #ifdefs in C code. Change requests can be kept separately in some kind of database (such as the FSF's GNATS system, or Mozilla's Bugzilla). Programmers can carry around in their heads the state needed to do renames without disruption.
As projects scale up in size and intricacy, however, such ad hoc measures increasingly fail to prevent damaging friction and lead to death by accumulated details. Complexity control for very large projects requires a fundamentally stronger (and, unfortunately, more constraining and complex) support environment that goes beyond version control—a full project-management system.
For more on the design issues in project-management systems, see the latter half of the book Applying SCCS and RCS by Don Bolinger and Tan Bronson (O'Reilly).
12.12 Using VC Effectively
We urge those of you with prior version control experience to heed the following maxim: to use VC effectively, check in your changes early and often! Of course, when you are working as part of a team of developers, you do need to take care to check in only a consistent and working set of files each time. There's nothing quite equal to the frustration of discovering that you can no longer compile and test your own code because someone else has checked in a fragmentary or broken piece of theirs.