Stephen Quinney
and 1 contributors


    LCFG::Build::VCS::CVS - LCFG build tools for CVS version-control


    This documentation refers to LCFG::Build::VCS::CVS version 0.2.3


    my $dir = ".";

    my $spec = LCFG::Build::PkgSpec->new_from_metafile("$dir/lcfg.yml");

    my $vcs = LCFG::Build::VCS::CVS->new( module  => $spec->fullname,
                                          workdir => $dir );


    if ( $vcs->checkcommitted() ) {


This is part of a suite of tools designed to provide a standardised interface to version-control systems so that the LCFG build tools can deal with project version-control in a high-level abstract fashion.

This module implements the interface specified by LCFG::Build::VCS. It provides support for LCFG projects which use the CVS version-control system. Facilities are available for procedures such as importing and exporting projects, doing tagged releases, generating the project changelog from the version-control log and checking all changes are committed.

More information on the LCFG build tools is available from the website



The name of the software package in this repository. This is required and there is no default value.


The directory in which the CVS commands should be carried out. This is required and if none is specified then it will default to '.', the current working directory. This must be an absolute path but if you pass in a relative path coercion will automatically occur based on the current working directory.


The name of the CVS executable, by default this is cvs.


This is the CVS root. If not specified the module will attempt to discover the right thing to use the first time you call the accessor. It will look into the CVS/Root file in the working directory for the project or if that fails use the CVSROOT environment variable.


This is a boolean value which controls the quietness of the CVS commands. By default it is false and commands, such as CVS, will print lots of extra stuff to the screen. If it is set to true the -Q option will be passed to the CVS binary whenever a command is executed. The cvs2cl(1) command used when automatically generating change log files will also honour this option.


This is a boolean value which controls whether the commands will actually have a real effect or just print out what would be done. By default it is false.


The name of the logfile to which information should be directed when doing version updates. This is also the name of the logfile to be used if you utilise the automatic changelog generation option. The default file name is 'ChangeLog'.


The following class methods are available:


Creates a new instance of the class.


This method returns a boolean value which indicates whether or not the specified directory is part of a checked out working copy of a CVS repository.

The following instance methods are available:


Test to see if there are any uncommitted files in the project directory. Note this test does not spot files which have not been added to the version-control system. In scalar context the subroutine returns 1 if all files are committed and 0 (zero) otherwise. In list context the subroutine will return this code along with a list of any files which require committing.


This method will generate a changelog (the name of which is controlled by the logname attribute) from the log kept within the version-control system. For CVS the cvs2cl(1) command is used.


This method is used to tag a set of files for a project at a particular version. It will also update the changelog appropriately. Tags are generated using the gen_tag() method, see below for details.


Tags are generated from the name and version details passed in by replacing any hyphens or dots with underscores and joining the two fields with an underscore. For example, lcfg-foo and 1.0.1 would become lcfg_foo_1_0_1.


A method used to handle the running of commands for the particular version-control system. This is required for systems like CVS where shell commands have to be executed. Not all modules will need to implement this method as they may well use a proper Perl module API (e.g. subversion).

export( $version, $builddir )

This will export a particular tagged version of the module. You need to specify the target "build" directory into which the exported tree will be put. The exported tree will be named like "modulename-version". For example:

  my $vcs = LCFG::Build::VCS::CVS->new(module => "lcfg-foo");
  $vcs->export( "1.2.3", "/tmp" );

Would give you an exported tree of code for the lcfg-foo module tagged as lcfg_foo_1_2_3 and it would be put into /tmp/lcfg-foo-1.2.3/

Returns the name of the directory into which the tree was exported.

export_devel( $version, $builddir )

This is similar to the export method. It takes the current working tree for a module and exports it directly to another tree based in the specified target "build" directory. This method copies over everything except the special CVS directories. For example:

  my $vcs = LCFG::Build::VCS::CVS->new(module => "lcfg-foo");
  $vcs->export_devel( "1.2.3_dev", "/tmp" );

Would give you an exported tree of code for the lcfg-foo module directory and it would be put into /tmp/lcfg-foo-1.2.3_dev/

Returns the name of the directory into which the tree was exported.

import_project( $dir, $version, $message )

Imports a project source tree into the version-control system. You need to specify the version for the initial tag. Optionally you can specify a message which will be used.


This is a convenience method which returns the full path to the logfile based on the workdir and logname attributes.


This module is Moose powered and it depends on LCFG::Build::VCS. You will need a working cvs executable somewhere on your system and a CVS repository for this module to be in anyway useful.


LCFG::Build::PkgSpec, LCFG::Build::VCS::None, LCFG::Build::VCS::SVN, LCFG::Build::Tools


This is the list of platforms on which we have tested this software. We expect this software to work on any Unix-like platform which is supported by Perl.

FedoraCore5, FedoraCore6, ScientificLinux5


There are no known bugs in this application. Please report any problems to, feedback and patches are also always very welcome.


    Stephen Quinney <>


Copyright (C) 2008-2013 University of Edinburgh. All rights reserved.

This library is free software; you can redistribute it and/or modify it under the terms of the GPL, version 2 or later.