vcp - Copy versions of files between repositories and/or RevML


   vcp [vcp_opts] <source> <dest>

   vcp help [topic]

   vcp html <destination dir>


vcp ('version copy') copies versions of files from one repository to another, translating as much metadata as possible along the way. This allows you to copy and translate files and their histories between revision storage systems.

Supported source and destination types are cvs:, p4:, and revml:.

Copying Versions

The general syntax of the vcp command line is:

   vcp [<vcp options>] <source> <dest>

The three portions of the command line are:

<vcp options>

Command line options that control the operation of the vcp command, like -d for debugging or -h for help. There are very few global options, these are covered below. Note that they must come before the <source> specification.


Were to extract versions from, including any command line options needed to control what is extracted and how. See the next section.


Where to insert versions, including any command line options needed to control how files are stored. See the next section.

Specifying Repositories

The <source> and <dest> specifications are meant to resemble URIs. They my have several fields delimited by : and @, and may have trailing command line options. The full (rarely used) syntax is:

   scheme:user(view):password@repository:filespec [<options>]



The repository type (p4:, cvs:, revml:).

user, view, and password

Optional values for authenticating with the repository and identifying which view to use. cvs does not use view. For p4, view is the client setting (equibalent to setting P4CLIENT or using p4's -c option).


The repository spec, CVSROOT for CVS or P4PORT for p4.


Which versions of what files to move. As much as possible, this spec is similar to the native filespecs used by the repository indicated by the scheme.


Command line options that usually mimic the options provided by the underlying repositories' command line tools (cvs, p4, etc).

Most of these fields are omitted in practice, only the scheme field is required, though (in most cases) the repository field is also needed unless you set the appropriate environment variables (CVSROOT, P4PORT, etc).

The a bit confusing, here are some examples specs:


Options and formats for of individual schemes can be found in the relevant help topics, for instance:

   vcp help source::cvs

See vcp help for a list of source and destination topics.

vcp Options

All general options to vcp must precede the <source>. Scheme-specific options must be placed immediately after the <source> or <dest> spec and before the next one.

--debug <spec>, -d <spec>

Enables display of debugging information. A debug spec is part or all of a module name like Source::revml or a perl5 regular expression to match module names. Debug specs are not case insensitively.

The most general, show-me-everything debug option is:

   -d ".*"

The quotations are needed to slip the ".*" past most command shells.

Any debug specs that don't match anything during a run are printed out when vcp exits in order to help identify mispelled patterns. vcp will also list all of the internal names that didn't match during a run to give clues as to what specs might be useful.

The special name 'what' is guaranteed to not match anything, so you can do

   vcp -d what ...

to see the list of names that might be useful for the arguments '...' .

You may use multiple -d options or provide a comma separated list to enable debugging within that module. Do not start a pattern with a "-".

Debugging messages are emitted to stderr. See "VCPDEBUG" for how to specify debug options in the environment.

--help, -h, -?

These are all equivalent to vcp help.

Getting help

(See also Generating HTML Documentation, below).

There is a slightly different command line format for requesting help:

   vcp help [<topic>]

where <topic> is the optional name of a topic. vcp help without a <topic> prints out a list of topics, and vcp help vcp emits this page.

All help documents are also available as Unix man pages and using the perldoc command, although the names are slightly different:

   with vcp               via perldoc        
   ================       ===========
   vcp help vcp           perldoc vcp
   vcp help source::cvs   perldoc VCP::Source::cvs
   vcp help source::cvs   perldoc VCP::Dest::p4

vcp help is case insensitive, perldoc and man may or may not be depending on your filesystem. The man commands look just like the example perldoc commands except for the command name. Both have the advantage that they use your system's configured pager if possible.

Environment Variables

The environment is often used to set context for the source and destination by way of variables like P4USER, P4CLIENT, CVSROOT, etc.

There is also one environment variable that is used to enable command line debugging. The VCPDEBUG variable acts just like a leading -d=$VCPDEBUG was present on the command line.


(see "--debug <spec>, -d <spec>" for more info). This is useful when VCP is embedded in another application, like a makefile or a test suite.

Generating HTML Documentation

All of the help pages in vcp can be built in to an HTML tree with the command:

   vcp html <dest_dir>

The index file will be <dest_dir>/index.html.


VCP::Process, VCP::Newlines, VCP::Source::p4, VCP::Dest::p4, VCP::Source::cvs, VCP::Dest::cvs, VCP::Source::revml, VCP::Dest::revml, VCP::Newlines. All are also available using vcp help.


Barrie Slaymaker <>


Copyright (c) 2000, 2001, 2002 Perforce Software, Inc. All rights reserved.

See VCP::License (vcp help license) for the terms of use.