Debra Cameron - Learning GNU Emacs, 3rd Edition

If you think that this situation has occurred, call vc-clear-context. This command forces VC to throw away all its cached-in-memory assumptions about the version control state of the files you are working with.

It is also theoretically possible for VC to get confused by a race condition between two or more VCs, or between VC and someone running the bare SCCS, RCS, or CVS utilities. This is not just a VC problem; the same sort of race is possible (though less likely) between two or more people running the bare utilities. However, this kind of race is very rare even in VC; the authors haven't heard of any instance in hundreds of thousands of programmer-hours in which it's known to have happened.

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.

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-headerswhen 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 makeand 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 tto 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-buffernormally 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 diffwhen generating a change report. VC uses it the same way. It defaults to the single switch -cto force context-diffformat; -ufor unified-diffformat is also fairly popular.

A number of other, less important global variables are fully documented in the Emacs online help system.

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.

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).