NAME

VCP::Source::p4 - A Perforce p4 repository source

SYNOPSIS

   vcp p4://depot/...@10          # all files after change 10 applied
   vcp p4://depot/...@1,10        # changes 1..10
   vcp p4://depot/...@-2,10       # changes 8..10
   vcp p4://depot/...@1,#head     # changes 1..#head
   vcp p4://depot/...@-2,#head    # changes 8..10
   vcp p4:...@-2,#head            # changes 8..10, if only one depot

To specify a user name of 'user', P4PASSWD 'pass', and port 'host:1666', use this syntax:

   vcp p4:user(client)password@host:1666:files

Note: the password will be passed in the environment variable P4PASSWD so it shouldn't show up in error messages. This means that a password specified in a P4CONFIG file will override the password you set on the command line. This is a bug. User, client and the server string will be passed as command line options to make them show up in error output.

You may use the P4... environment variables instead of any or all of the fields in the p4: repository specification. The repository spec overrides the environment variables.

DESCRIPTION

Driver to allow vcp to extract files from a Perforce repository.

Note that not all metadata is extracted: users, clients and job tracking information is not exported, and only label names are exported.

Also, the 'time' and 'mod_time' attributes will lose precision, since p4 doesn't report them down to the minute. Hmmm, seems like p4 never sets a true mod_time. It gets set to either the submit time or the sync time. From p4 help client:

    modtime         Causes 'p4 sync' to force modification time 
		    to when the file was submitted.

    nomodtime *     Leaves modification time set to when the
		    file was fetched.

OPTIONS

-b, --bootstrap

   -b '...'
   --bootstrap='...'
   -b file1[,file2[,...]]
   --bootstrap=file1[,file2[,...]]

(the ... there is three periods, a p4 wildcard implemented by Regexp::Shellish.

Forces bootstrap mode for an entire export (-b '...') or for certain files. Filenames may contain wildcards, see Regexp::Shellish for details on what wildcards are accepted.

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.

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.

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.

This option is necessary when exporting only more recent revisions from a repository.

--follow-branch-into

Causes VCP to notice "branch into" messages in the filelog and, if the target revision number is #1, add the target file to the list of exported files. This usually needs a --rev-root option to set the rev root to be high enough in the directory tree to include all branches (it's an error to export a file that is not under the rev root).

-r, --rev-root

Sets the "revisions" root of the source tree being extracted; without this option, VCP assumes that you are extracting the directory tree ending in the last path segment in the filespec without a wildcard. This allows you to specify a shorter root directory, which can be useful especially with --follow-branch-into, since branches may often lead off from the current directory to peer directories or even in to entirely different trees.

The default rev-root is the file spec up to the first path segment (directory name) containing a wildcard, so

   p4:/a/b/c...

would have a rev root of /a/b.

In direct repository-to-repository transfers, this option should not be necessary, the destination filespec overrides it.

LIMITATIONS

Treats each branched file as a separate branch with a unique branch_id, although files that are branched together should end up being submitted together in the destination repository due to change number aggregation.

Ignores branch specs for now. There may be an option to enable automatic use of branch specs because most are probably well behaved. However, in the event of a branch spec being altered after the original branch, this could lead to odd results. Not sure how useful branch specs are vs. how likely a problem this is to be. We may also want to support "external" branch specs to allow deleted branch specs to be used.

SEE ALSO

VCP::Dest::p4, vcp.

AUTHOR

Barrie Slaymaker <barries@slaysys.com>

COPYRIGHT

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

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