We are all used to working collaboratively on site development and to using the Concurrent Version System (CVS) for managing the code base as the site is programmed. But what about modules that provide access to site content or software management tools? Do we give up version control in this case? Do we have to rewrite the machinery of a system like CVS? Absolutely not.
The VC application provides a simple interface to CVS that can be used by any application to add version control capabilities to that application. It also provides procedures to obtain version control information for any file associated with the project, e.g., to display additional information in the page footer or for integration with bug tracking systems.
The VC application does not have any user pages, just a set of procedures that allow you to access the version control system. Every procedure takes the full pathname of a file on which it is to operate. The public API consist of a number of simple wrappers to corresponding CVS commands.
Users of the VC application will be developers who need to access file-level version control information from within their applications.
None.
An individual query can be relatively expensive with respect to completion time, particularly if CVS has to go over the network to access information from a remote repository. Therefore, all information managed by the VC application is cached within the server based on the modification time of the corresponding file.
$Log: requirements.html,v $ Revision 1.1.1.1 2001/04/20 20:51:23 donb Forgot to define binary files before importing, so .gifs were messed up. Revision 1.4 2000/12/08 02:43:20 jfinkler minor change Revision 1.3 2000/12/08 02:37:38 jfinkler some terminological revision Revision 1.2 2000/11/21 07:08:57 ron corrected section labels Revision 1.1.1.1 2000/11/21 07:00:49 ron initial version