VCS_dev - Information for VCS::* developers

VCS_dev provides internal API information for generic VCS::* programming access in Perl. This document is for VCS::* developers, not necessarily for users of VCS itself.

CWVCS is an API for abstracting access to all version control systems from Perl code. This is achieved in a similar fashion to the CWDBI suite of modules. There are container classes, CWVCS::Dir, CWVCS::File, and CWVCS::Version, and implementation classes, such as CWVCS::Cvs::Dir, CWVCS::Cvs::File, and CWVCS::Cvs::Version, which are subclasses of their respective container classes.

The container classes are instantiated with URLs. There is a URL scheme for entities under version control. The format is as follows:

    vcs://localhost/VCS::Cvs/fs/path/?query=1

The query part is ignored for now. The path must be an absolute path, meaningful to the given class. The class is an implementation class, such as CWVCS::Cvs.

The container classes work as follows: when the CWnew method of a container class is called, it will parse the given URL, using the CWVCS->parse_url method. It will then call the CWnew of the implementation's appropriate container subclass, and return the result. For example,

    VCS::Version->new('vcs://localhost/VCS::Cvs/fs/path/file/1.2');

will return a CWVCS::Cvs::Version.

For the purposes of concretely illustrating the layout of an implementation suppose that there is a need for a VCS::Imp or CW$Imp implementation.

An implementation class is recognised as follows: its name starts with CWVCS::, and CWrequire "VCS/Imp.pm" will load the appropriate implementation classes corresponding to the container classes - CWVCS::Imp::Dir, CWVCS::Imp::File and CWVCS::Imp::Version..

Hence in MANIFEST, or Unix file specificaton, syntax the Imp implementation ought to be composed of at least these files:

    VCS/Imp.pm
    VCS/Imp/Dir.pm
    VCS/Imp/File.pm
    VCS/Imp/Version.pm

In addition to the usual module distribution files such as MANIFEST, Makefile.PL, etc.

Implementation classes must include documentation for their special requirements, such as mandatory environment variables. See VCS::Cvs for an example.

If a method, or an argument to a method makes no sense for a particular implementation, then the implementation may ignore it, but must do so quietly.

The modules that make up a VCS implementation might act as wrappers around a command language interpreter (CLI or shell) command, or might directly look at files or talk over the network. It is recommended that before implementing a VCS::*::* class that implements direct access, the developer first implement a version that uses the CLI tools, and writes appropriate tests for it. Doing this will ensure that the direct-access version, which passes the tests, will be correct.

* VCS/Imp.pm

The variable CW$LOG_CMD is the CLI command for obtaining revision history logs. This module typically implements five distinct non-public sub routines: CWsub _boiler_plate_info {}, CWsub _split_log {}, CWsub _parse_log_rev {}, CWsub _parse_log_header {}, CWsub _read_pipe {} is for reading from the CLI.

* VCS/Imp/Dir.pm

This module implements three public sub routines/methods: CWsub new {}, CWsub name {}, CWsub content {}.

* VCS/Imp/File.pm

Revisions should be returned in reverse time order (latest first, oldest last). This module implements three public sub routines/methods: CWsub new {}, CWsub name {}, CWsub versions {}.

* VCS/Imp/Version.pm

The variable CW$DIFF_CMD is the CLI command for doing diffs. The variable CW$UPDATE_CMD is the CLI command for doing updates. This module implements nine public sub routines/methods: CWsub new {}, CWsub name {}, CWsub version {}, CWsub tags {}, CWsub text {}, CWsub diff {}, CWsub author {}, CWsub date {}, CWsub reason {}.

If you prefer there is a pod stub in Imp_pod.tpl that you could catenate onto the tail of your VCS/$Imp.pm file, making sure to edit the template with CWs/Imp/$Your_VCS_Name/g. For simple version control system APIs (i.e. with a CLI interface and no need for XS, C, or header file worries) an easy way to get started would be to use h2xs like so:

    h2xs -AXf -n VCS::Imp

then add a VCS/Imp/VCS directory and put appropriate File.pm, Dir.pm and Version.pm modules in it (add them the the MANIFEST as well). If calling in to your version control system requires XS then omit the CW-X and CW-f switches and specify the header file name.

You might also be interested in looking at the other implementations for tips on how to map your version control systems' CLI commands to VCS::* methods. For parsing details it can prove helpful to see an example of the output of some of the other version control systems. (e.g. the output of the CW$LOG_CMD in typical usage).

* VCS/Cvs.pm

The variable CW$LOG_CMD is CW'cvs log'.

* VCS/Cvs/Dir.pm

* VCS/Cvs/File.pm

* VCS/Cvs/Version.pm

The variable CW$DIFF_CMD is CW'cvs diff -u2'. The variable CW$UPDATE_CMD is CW'cvs update -p'.

* VCS/Rcs.pm

The variable CW$LOG_CMD is CW'rlog'.

* VCS/Rcs/Dir.pm

* VCS/Rcs/File.pm

* VCS/Rcs/Version.pm

The variable CW$DIFF_CMD is CW'rcsdiff -u2'. The variable CW$UPDATE_CMD is CW'co -p'.

* VCS/Hms.pm

The variable CW$LOG_CMD is CW'flog'.

* VCS/Hms/Dir.pm

* VCS/Hms/File.pm

* VCS/Hms/Version.pm

The variable CW$DIFF_CMD is CW'fdiff'. The variable CW$UPDATE_CMD is CW'fco -p'. flog output is reversed here.

Where are the wrappers around rcs's ci or CVS's cvs ci? (This is listed as a known BUG in that VCS is currently read only).

Does Hms have a fci command?

See the pod in VCS/File.pm for other unimplemented things.

VCS, and the generic implementation in VCS::Dir, VCS::File, and VCS::Version.

The CVS implementation is in VCS::Cvs along with the unpodded VCS/Cvs/*.pm modules.

The Hms implementation is in VCS::Hms along with the unpodded VCS/Hms/*.pm modules.

The rcs implementation is in VCS::Rcs along with the unpodded VCS/Rcs/*.pm modules.