<html><head><title>VCP::Source::vss - A VSS repository source</title></head><body><h1><a name="NAME">NAME
</a></h1><p>VCP::Source::vss - A VSS repository source
<p><hr><h1><a name="SYNOPSIS">SYNOPSIS
</a></h1><pre> vcp vss:project/...
</pre><p><hr><h1><a name="DESCRIPTION">DESCRIPTION
</a></h1><p>Source driver enabling <a href="../../vcp.html">vcp</a> to extract versions form a vss
repository.
<p>The source specification for VSS looks like:
<pre> vss:filespec [<options>]
</pre><p><code>filespec</code> may contain trailing wildcards, like <code>/a/b/...</code> to extract
an entire directory tree (this is the normal case).
<p>NOTE: This does not support incremental exports, see LIMITATIONS.
<p><hr><h1><a name="OPTIONS">OPTIONS
</a></h1><dl><dt><a name="_b_bootstrap_"><strong><p>-b, --bootstrap
</strong></a><pre> -b ...
--bootstrap=...
-b file1[,file2[, etc.]]
--bootstrap=file1[,file2[, etc. ]]
</pre><dd>(the <code>...</code> there is three periods, a
<a>Regexp::Shellish</a> wildcard borrowed from <code>p4</code>
path syntax).
<p>Forces bootstrap mode for an entire export (<code>-b ...</code>) or for certain
files. Filenames may contain wildcards, see <a>Regexp::Shellish</a> for
details on what wildcards are accepted.
<p>Controls how the first revision of a file is exported. A bootstrap
export contains the entire contents of the first revision in the
revision range. This should only be necessary when exporting for the
first time.
<p>An incremental export contains a digest of the revision preceding the
first revision in the revision range, followed by a delta record between
that revision and the first revision in the range. This allows the
destination import function to make sure that the incremental export
begins where the last export left off.
<p>The default is decided on a per-file basis: if the first revision in the
range is revision #.1, the full contents are exported. Otherwise an
incremental export is done for that file.
<p>This option is necessary when exporting only more recent revisions from
a repository.
<dt><a name="_cd_"><strong><p>--cd
</strong></a><dd>Used to set the VSS working directory. VCP::Source::vss will cd to this
directory before calling vss, and won't initialize a VSS workspace of
it's own (normally, VCP::Source::vss does a "vss checkout" in a
temporary directory).
<p>This is an advanced option that allows you to use a VSS workspace you
establish instead of letting vcp create one in a temporary directory
somewhere. This is useful if you want to read from a VSS branch or if
you want to delete some files or subdirectories in the workspace.
<p>If this option is a relative directory, then it is treated as relative
to the current directory.
<dt><a name="_rev_root_"><strong><p>--rev-root
</strong></a><dd><b>Experimental</b>.
<p>Falsifies the root of the source tree being extracted; files will
appear to have been extracted from some place else in the hierarchy.
This can be useful when exporting RevML, the RevML file can be made
to insert the files in to a different place in the eventual destination
repository than they existed in the source repository.
<p>The default <code>rev-root</code> is the file spec up to the first path segment
(directory name) containing a wildcard, so
<pre> vss:/a/b/c...
</pre><p>would have a rev-root of <code>/a/b</code>.
<p>In direct repository-to-repository transfers, this option should not be
necessary, the destination filespec overrides it.
</dl><h2><a name="Files_that_aren_t_tagged">Files that aren't tagged
</a></h2><p>VSS has one peculiarity that this driver works around.
<p>If a file does not contain the tag(s) used to select the source files,
<code>vss log</code> outputs the entire life history of that file. We don't want
to capture the entire history of such files, so <a href="vss.html">VCP::Source::vss</a> goes
ignores any revisions before and after the oldest and newest tagged file
in the range.
<p><hr><h1><a name="LIMITATIONS">LIMITATIONS
</a></h1><pre> "What we have here is a failure to communicate!"
- The warden in Cool Hand Luke
</pre><p>VSS does not try to protect itself from people checking in things that
look like snippets of VSS log file: they come out exactly like they
went in, confusing the log file parser.
<p>So, if a repository contains messages in the log file that look like the
output from some other "vss log" command, things will likely go awry.
<p>At least one vss repository out there has multiple revisions of a single file
with the same rev number. The second and later revisions with the same rev
number are ignored with a warning like "Can't add same revision twice:...".
<p><hr><h1><a name="VSS_NOTES">VSS NOTES
</a></h1><p>We lose comments attached to labels: labels are added to the last
"real" (ie non-label-only) revision and the comments are ignored.
This can be changed, contact me.
<p>We assume a file has always been text or binary, don't think this is
stored per-version in VSS.
<p>Looks for deleted files: recovers them if found just long enough to
cope with them, then deletes them again.
<p>VSS does not track renames by version, so a previous name for a file is lost.
<p>VSS lets you add a new file after deleting an old one. This module
renames the current file, restores the old one, issues its revisions,
then deletes the old on and renames the current file back. In this
case, the <code>rev_id</code>s from the current file start at the highest
<code>rev_id</code> for the deleted file and continue up.
<p>NOTE: when recovering a deleted file and using it, the current version
takes a "least opportunity to screw up the source repository" approach:
it renames the not-deleted version (if any), restores the deleted one,
does the History or Get, and then deletes it and renames the not-deleted
version back.
<p>This is so that if something (the OS, the hardware, AC mains, or even
VCP code) crashes, the source repository is left as close to the
original state as is possible. This does mean that this module can
issue many more commands than minimally necessary; perhaps there should
be a --speed-over-safety option.
<p>No incremental export is supported. VSS' -V~Lfoo option, which says
"all versions since this label" does not actually cause the <code>ss.exe
History</code> command to emit the indicated checkin. We'll need to make the
history command much smarter to implement that.
<p><hr><h1><a name="SEE_ALSO">SEE ALSO
</a></h1><p><a href="../Dest/vss.html">VCP::Dest::vss</a>, <a href="../../vcp.html">vcp</a>, <a href="../Process.html">VCP::Process</a>.
<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="../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:23 2002</font></i></body></html>