<html><head><title>vcp - Copy versions of files between repositories and/or RevML</title></head><body><h1><a name="NAME">NAME
</a></h1><p>vcp - Copy versions of files between repositories and/or RevML
<p><hr><h1><a name="SYNOPSIS">SYNOPSIS
</a></h1><pre> vcp [vcp_opts] <source> <dest>
</pre><pre> vcp help [topic]
</pre><pre> vcp html <destination dir>
</pre><p><hr><h1><a name="DESCRIPTION">DESCRIPTION
</a></h1><p><code>vcp</code> ('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.
<p>Supported source and destination types are <code>cvs:</code>, <code>p4:</code>, and <code>revml:</code>.
<h2><a name="Copying_Versions">Copying Versions
</a></h2><p>The general syntax of the vcp command line is:
<pre> vcp [<vcp options>] <source> <dest>
</pre><p>The three portions of the command line are:
<dl><dt><a name="_vcp_options_"><strong><p><code><vcp options></code>
</strong></a><dd>Command line options that control the operation of the <code>vcp</code> command, like
<code>-d</code> for debugging or <code>-h</code> for help. There are very few global options,
these are covered below. Note that they must come before the
<code><source></code> specification.
<dt><a name="_source_"><strong><p><code><source></code>
</strong></a><dd>Were to extract versions from, including any command line options needed to
control what is extracted and how. See the next section.
<dt><a name="_dest_"><strong><p><code><dest></code>
</strong></a><dd>Where to insert versions, including any command line options needed to control
how files are stored. See the next section.
</dl><h2><a name="Specifying_Repositories">Specifying Repositories
</a></h2><p>The <code><source></code> and <code><dest></code> specifications specify a
repository and provide any options needed for accessing that repository.
<p>These spefications may be a simple filename for reading or writing RevML
files (if the requisite XML handling modules are installed). or a full
repository specification like <code>cvs:/home/cvs/root:module</code> or
<code>p4:user:password@server:port://depot/dir</code>.
<p>When using the long form to access a repository, <code><source></code> and
<code><dest></code> specification have several fields delimited by <code>:</code>
and <code>@</code>, and may have trailing command line options. The full (rarely
used) syntax is:
<pre> scheme:user(view):password@repository:filespec [<options>]
</pre><p>where
<dl><dt><a name="scheme_"><strong><p><code>scheme:</code>
</strong></a><dd>The repository type (<code>p4:</code>, <code>cvs:</code>, <code>revml:</code>).
<dt><a name="user"><strong><p><code>user</code>, <code>view</code>, and <code>password</code>
</strong></a><dd>Optional values for authenticating with the repository and identifying which
view to use. <code>cvs</code> does not use <code>view</code>. For <code>p4</code>, <code>view</code> is the client
setting (equibalent to setting <code>P4CLIENT</code> or using <code>p4</code>'s <code>-c</code> option).
<dt><a name="repository"><strong><p><code>repository</code>
</strong></a><dd>The repository spec, CVSROOT for CVS or P4PORT for p4.
<dt><a name="filespec"><strong><p><code>filespec</code>
</strong></a><dd>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.
<dt><a name="_options_"><strong><p><code><options></code>
</strong></a><dd>Command line options that usually mimic the options provided by the underlying
repositories' command line tools (<code>cvs</code>, <code>p4</code>, etc).
</dl><p>Most of these fields are omitted in practice, only the <code>scheme</code> field is
required, though (in most cases) the <code>repository</code> field is also needed unless
you set the appropriate environment variables (<code>CVSROOT</code>, <code>P4PORT</code>, etc).
<p>The a bit confusing, here are some examples specs:
<pre> cvs:server:/foo
p4:user@server://depot/foo/...
p4:user:password@public.perforce.com:1666://depot/foo/...
</pre><p>Options and formats for of individual schemes can be found in the relevant
help topics, for instance:
<pre> vcp help source::cvs
</pre><p>See <code>vcp help</code> for a list of source and destination topics.
<p>When reading and writing RevML files, a simple filename will do
(although the long form may also be used). The special value "-" means
to read/write stdin and stdout when used as a source or destination
name, respectively. "-" is assumed if a specification is not provided,
so these invocations all accomplish the same thing, reading and writing
RevML:
<pre> vcp
vcp -
vcp revml:-
vcp revml:
vcp - -
vcp - revml:-
vcp - revml:
vcp revml:- revml:-
vcp revml: revml:
</pre><h2><a name="vcp_Options"><code>vcp</code> Options
</a></h2><p>All general options to vcp must precede the <code><source></code>.
Scheme-specific options must be placed immediately after the
<code><source></code> or <code><dest></code> spec and before the next one.
<dl><dt><a name="_debug_spec_d_spec_"><strong><p>--debug <spec>, -d <spec>
</strong></a><dd>Enables display of debugging information. A debug spec is part or all of a
module name like <code>Source::revml</code> or a perl5 regular expression to match module
names. Debug specs are not case insensitively.
<p>The most general, show-me-everything debug option is:
<pre> -d ".*"
</pre><p>The quotations are needed to slip the ".*" past most command shells.
<p>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.
<p>The special name 'what' is guaranteed to not match anything, so you can
do
<pre> vcp -d what ...
</pre><p>to see the list of names that might be useful for the arguments '...' .
<p>You may use multiple
<code>-d</code> options or provide a comma separated list to enable debugging
within that module. Do not start a pattern with a "-".
<p>Debugging messages are emitted to stderr. See <a href="#VCPDEBUG">/VCPDEBUG</a> for how to specify
debug options in the environment.
<dt><a name="_help_h_"><strong><p>--help, -h, -?
</strong></a><dd>These are all equivalent to <code>vcp help</code>.
</dl><h2><a name="Getting_help">Getting help
</a></h2><p>(See also <a href="#Generating_HTML_Documentation">Generating HTML Documentation</a>,
below).
<p>There is a slightly different command line format for requesting help:
<pre> vcp help [<topic>]
</pre><p>where <code><topic></code> is the optional name of a topic. <code>vcp help</code> without
a <code><</code>topic<code>></code> prints out a list of topics, and <code>vcp help vcp</code>
emits this page.
<p>All help documents are also available as Unix <code>man</code> pages and using the
<code>perldoc</code> command, although the names are slightly different:
<pre> 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
</pre><p><code>vcp help</code> is case insensitive, <code>perldoc</code> and <code>man</code> may or may not be
depending on your filesystem. The <code>man</code> commands look just like the example
<code>perldoc</code> commands except for the command name. Both have the advantage that
they use your system's configured pager if possible.
<h2><a name="Environment_Variables">Environment Variables
</a></h2><dl><dt><a name="VCPDEBUG_"><strong><p>VCPDEBUG
</strong></a><dd>The environment is often used to set context for the source and destination
by way of variables like P4USER, P4CLIENT, CVSROOT, etc.
<p>There is also one environment variable that is used to enable
command line debugging. The VCPDEBUG variable acts just like a leading
<code>-d=$VCPDEBUG</code> was present on the command line.
<pre> VCPDEBUG=main,p4
</pre><p>(see <a href="#_debug_spec_d_spec_">"--debug <spec>, -d <spec>"</a> for more info). This is useful when VCP is
embedded in another application, like a makefile or a test suite.
</dl><h2><a name="Generating_HTML_Documentation">Generating HTML Documentation
</a></h2><p>All of the help pages in <code>vcp</code> can be built in to an HTML tree with the
command:
<pre> vcp html <dest_dir>
</pre><p>The index file will be <code><dest_dir>/index.html</code>.
<p><hr><h1><a name="SEE_ALSO">SEE ALSO
</a></h1><p><a href="VCP/Process.html">VCP::Process</a>, <a href="VCP/Newlines.html">VCP::Newlines</a>, <a href="VCP/Source/p4.html">VCP::Source::p4</a>, <a href="VCP/Dest/p4.html">VCP::Dest::p4</a>,
<a href="VCP/Source/cvs.html">VCP::Source::cvs</a>, <a href="VCP/Dest/cvs.html">VCP::Dest::cvs</a>, <a href="VCP/Source/revml.html">VCP::Source::revml</a>,
<a href="VCP/Dest/revml.html">VCP::Dest::revml</a>, <a href="VCP/Newlines.html">VCP::Newlines</a>. All are also available using <code>vcp
help</code>.
<p><hr><h1><a name="AUTHOR">AUTHOR
</a></h1><p>Barrie Slaymaker <barries@slaysys.com>
<p><hr><h1><a name="COPYRIGHT">COPYRIGHT
</a></h1><p>Copyright (c) 2000, 2001, 2002 Perforce Software, Inc.
All rights reserved.
<p>See <a href="VCP/License.html">VCP::License</a> (<code>vcp help license</code>) for the terms of use.
<p><hr><i><font size="-1">Last updated: Fri Nov 8 13:07:22 2002</font></i></body></html>