Files larger than 1 MB are truncated. Click
here to display the full file (may cause the browser to become unresponsive) or use the
Open button to view outside of Swarm.
<?xml version="1.0"?>
<doc>
<assembly>
<name>p4api.net</name>
</assembly>
<members>
<member name="T:Perforce.P4.StrDictListIterator">
<summary>
The StrDictListIterator represents the iterator functions exposed by
the P4 bridge dll to allow the client to read structured (tagged) data.
It is not exposed outside the p4.net assembly as the P4Server class
translates the raw data into a .NET array list of hash tables.
</summary>
</member>
<member name="T:Perforce.P4.KeyValuePair">
<summary>
Simple calls used to read key:value pairs from a StrDict object
referenced by a pointer returned from the bridge
</summary>
</member>
<member name="T:Perforce.P4.ErrorSeverity">
<summary>
Error severity levels.
</summary>
</member>
<member name="F:Perforce.P4.ErrorSeverity.E_UNKNOWN">
<summary>
Unknown
</summary>
</member>
<member name="F:Perforce.P4.ErrorSeverity.E_EMPTY">
<summary>
nothing yet
</summary>
</member>
<member name="F:Perforce.P4.ErrorSeverity.E_INFO">
<summary>
something good happened
</summary>
</member>
<member name="F:Perforce.P4.ErrorSeverity.E_WARN">
<summary>
something not good happened
</summary>
</member>
<member name="F:Perforce.P4.ErrorSeverity.E_FAILED">
<summary>
user did something wrong
</summary>
</member>
<member name="F:Perforce.P4.ErrorSeverity.E_FATAL">
<summary>
system broken -- nothing can continue
</summary>
</member>
<member name="F:Perforce.P4.ErrorSeverity.E_NOEXC">
<summary>
Used to turnoff exceptions
</summary>
</member>
<member name="T:Perforce.P4.P4ClientError">
<summary>
Class used to return a single error or warning from the bridge dll.
</summary>
</member>
<member name="F:Perforce.P4.P4ClientError.SeverityLevel">
<summary>
How severe is the error
</summary>
</member>
<member name="F:Perforce.P4.P4ClientError.ErrorCode">
<summary>
Generic code for the error
</summary>
</member>
<member name="F:Perforce.P4.P4ClientError.ErrorMessage">
<summary>
Descriptive error message
</summary>
</member>
<member name="M:Perforce.P4.P4ClientError.#ctor(Perforce.P4.ErrorSeverity,System.String)">
<summary>
Create a new ClientError
</summary>
<param name="severityLevel"></param>
<param name="errorMessage"></param>
</member>
<member name="M:Perforce.P4.P4ClientError.#ctor(Perforce.P4.P4Server,System.IntPtr)">
<summary>
Create a new ClientError
</summary>
<param name="severityLevel"></param>
<param name="errorMessage"></param>
</member>
<member name="M:Perforce.P4.P4ClientError.ToString">
<summary>
Format the error in the form [ErrorLevel] Message
</summary>
<returns></returns>
</member>
<member name="T:Perforce.P4.P4ClientErrorList">
<summary>
Class used to return a list of errors and warnings returned by a command.
</summary>
</member>
<member name="M:Perforce.P4.P4ClientErrorList.Init(Perforce.P4.P4Server,System.IntPtr)">
<summary>
Read an error list from the server by traversing the linked list.
</summary>
<param name="p4Server">Perforce server</param>
<param name="pObj">First error in the list</param>
</member>
<member name="M:Perforce.P4.P4ClientErrorList.#ctor(Perforce.P4.P4ClientError)">
<summary>
Create a list of a single error
</summary>
<param name="Err">Error</param>
</member>
<member name="M:Perforce.P4.P4ClientErrorList.#ctor(System.String,Perforce.P4.ErrorSeverity)">
<summary>
Create a list of a single error
</summary>
<param name="msg">Error message</param>
<param name="severity">Severity level</param>
</member>
<member name="M:Perforce.P4.P4ClientErrorList.#ctor(Perforce.P4.P4Server,System.IntPtr)">
<summary>
Read the error list from the server
</summary>
<param name="p4Server"></param>
<param name="pObj"></param>
</member>
<member name="M:Perforce.P4.P4ClientErrorList.#ctor(Perforce.P4.P4Server,System.UInt32)">
<summary>
Create a list from the current error results on the server
</summary>
<param name="p4Server">Perforce Server</param>
</member>
<member name="M:Perforce.P4.P4ClientErrorList.op_Implicit(Perforce.P4.P4ClientErrorList)~System.String[]">
<summary>
Cast the errors to a String[]
</summary>
<param name="l">the list to cast </param>
<returns></returns>
</member>
<member name="M:Perforce.P4.P4ClientErrorList.op_Implicit(Perforce.P4.P4ClientErrorList)~System.String">
<summary>
Cast the errors to a String. Each error is separated by \r\n
</summary>
<param name="l">the list to cast </param>
<returns></returns>
</member>
<member name="T:Perforce.P4.P4ClientInfoMessage">
<summary>
Class used to return a info message from the bridge dll.
</summary>
</member>
<member name="F:Perforce.P4.P4ClientInfoMessage.MessageLevel">
<summary>
Message level
</summary>
</member>
<member name="F:Perforce.P4.P4ClientInfoMessage.MessageCode">
<summary>
Generic code for the message
</summary>
</member>
<member name="F:Perforce.P4.P4ClientInfoMessage.Message">
<summary>
Message
</summary>
</member>
<!-- Badly formed XML comment ignored for member "M:Perforce.P4.P4ClientInfoMessage.#ctor(System.Int32,System.Int32,System.String)" -->
<member name="M:Perforce.P4.P4ClientInfoMessage.#ctor(Perforce.P4.P4Server,System.IntPtr)">
<summary>
Create a new P4ClientInfoMessage
</summary>
<param name="severityLevel"></param>
<param name="errorMessage"></param>
</member>
<member name="T:Perforce.P4.P4ClientInfoMessageList">
<summary>
Class used to return a list of info Messages returned by a command.
</summary>
</member>
<member name="M:Perforce.P4.P4ClientInfoMessageList.Init(Perforce.P4.P4Server,System.IntPtr)">
<summary>
Read an error list from the server by traversing the linked list.
</summary>
<param name="p4Server">Perforce server</param>
<param name="pObj">First error in the list</param>
</member>
<member name="M:Perforce.P4.P4ClientInfoMessageList.#ctor">
<summary>
Create an empty list
</summary>
<param name="Msg">Error</param>
</member>
<member name="M:Perforce.P4.P4ClientInfoMessageList.#ctor(Perforce.P4.P4ClientInfoMessage)">
<summary>
Create a list of a single error
</summary>
<param name="Msg">Error</param>
</member>
<member name="M:Perforce.P4.P4ClientInfoMessageList.#ctor(System.String,System.Int32)">
<summary>
Create a list of a single error
</summary>
<param name="msg">Error message</param>
<param name="level">Message level</param>
</member>
<member name="M:Perforce.P4.P4ClientInfoMessageList.#ctor(Perforce.P4.P4Server,System.IntPtr,System.Int32)">
<summary>
Read the error list from the server
</summary>
<param name="p4Server"></param>
<param name="pObj"></param>
</member>
<member name="M:Perforce.P4.P4ClientInfoMessageList.#ctor(Perforce.P4.P4Server,System.UInt32)">
<summary>
Create a list from the current error results on the server
</summary>
<param name="p4Server">Perforce Server</param>
</member>
<member name="M:Perforce.P4.P4ClientInfoMessageList.op_Implicit(Perforce.P4.P4ClientInfoMessageList)~System.String[]">
<summary>
Cast the messages to a String[]
</summary>
<param name="l">the list to cast </param>
<returns></returns>
</member>
<member name="M:Perforce.P4.P4ClientInfoMessageList.op_Implicit(Perforce.P4.P4ClientInfoMessageList)~System.String">
<summary>
Cast the errors to a String. Each error is separated by \r\n
</summary>
<param name="l">the list to cast </param>
<returns></returns>
</member>
<member name="T:Perforce.P4.PinnedByteArray">
<summary>
Used to wrap a byte[] that is pinned in memory to pass down to the dll.
In general, since .NET does not natively support marshaling Strings to
UTF-8 for char * parameters, we must do our own encoding of the
strings into byte[], pin them, pass them to the dll, and then free the
pinned memory on return. This class wraps that process with an
IDisposable object to ensure the memory is freed after the call.
</summary>
</member>
<member name="T:Perforce.P4.P4ClientResolve">
<summary>
Class containing the DLL imports for the P4Bridge DLL.
</summary>
</member>
<member name="T:Perforce.P4.PinnedByteArrays">
<summary>
Wrapper for an array of PinnedByteArrays, used to wrap the arg list
passed to a command to make sure the pinned memory is freed.
</summary>
</member>
<member name="T:Perforce.P4.Repository">
<summary>
Represents a Perforce server and connection.
</summary>
</member>
<member name="M:Perforce.P4.Repository.GetServerMetaData">
<summary>
</summary>
<returns></returns>
</member>
<member name="M:Perforce.P4.Repository.GetServerMetaData(Perforce.P4.Options)">
<summary>
Get server information.
</summary>
<returns>Information about a connection's client-side application context.</returns>
<remarks>
<br/><b>p4 help info</b>
<br/>
<br/> info -- Display client/server information
<br/>
<br/> p4 info [-s]
<br/>
<br/> Info lists information about the current client (user name,
<br/> client name, applicable client root, client current directory,
<br/> and the client IP address) and some server information (server
<br/> IP address, server root, date, uptime, version and license data).
<br/>
<br/> The -s option produces 'short' output that omits any information
<br/> that requires a database lookup such as the client root).
<br/>
<br/>
</remarks>
<example>
To get the server root:
<code>
ServerMetaData s = rep.GetServerMetaData(null);
string root = s.Root;
</code>
To get the server case handling:
<code>
ServerMetaData s = rep.GetServerMetaData(null);
bool caseSensitive = s.CaseSensitive;
</code>
</example>
</member>
<member name="M:Perforce.P4.Repository.CreateBranchSpec(Perforce.P4.BranchSpec,Perforce.P4.Options)">
<summary>
Create a new branch in the repository.
</summary>
<param name="branch">Branch specification for the new branch</param>
<param name="options">The '-i' flag is required when creating a new branch </param>
<returns>The Branch object if new branch was created, null if creation failed</returns>
<remarks>
<br/>
<br/><b>p4 help branch</b>
<br/>
<br/> branch -- Create, modify, or delete a branch view specification
<br/>
<br/> p4 branch [-f] name
<br/> p4 branch -d [-f] name
<br/> p4 branch [ -S stream ] [ -P parent ] -o name
<br/> p4 branch -i [-f]
<br/>
<br/> A branch specification ('spec') is a named, user-defined mapping of
<br/> depot files to depot files. It can be used with most of the commands
<br/> that operate on two sets of files ('copy', 'merge', 'integrate',
<br/> 'diff2', etc.)
<br/>
<br/> Creating a branch spec does not branch files. To branch files, use
<br/> 'p4 copy', with or without a branch spec.
<br/>
<br/> The 'branch' command puts the branch spec into a temporary file and
<br/> invokes the editor configured by the environment variable $P4EDITOR.
<br/> Saving the file creates or modifies the branch spec.
<br/>
<br/> The branch spec contains the following fields:
<br/>
<br/> Branch: The branch spec name (read only).
<br/>
<br/> Owner: The user who created this branch spec. Can be changed.
<br/>
<br/> Update: The date this branch spec was last modified.
<br/>
<br/> Access: The date of the last command used with this spec.
<br/>
<br/> Description: A description of the branch spec (optional).
<br/>
<br/> Options: Flags to change the branch spec behavior. The defaults
<br/> are marked with *.
<br/>
<br/> locked Permits only the owner to change the spec.
<br/> unlocked * Prevents the branch spec from being deleted.
<br/>
<br/> View: Lines mapping of one view of depot files to another.
<br/> Both the left and right-hand sides of the mappings refer
<br/> to the depot namespace. See 'p4 help views' for more on
<br/> view syntax.
<br/>
<br/> New branch specs are created with a default view that maps all depot
<br/> files to themselves. This view must be changed before the branch
<br/> spec can be saved.
<br/>
<br/> The -d flag deletes the named branch spec.
<br/>
<br/> The -o flag writes the branch spec to standard output. The user's
<br/> editor is not invoked.
<br/>
<br/> The -i flag causes a branch spec to be read from the standard input.
<br/> The user's editor is not invoked.
<br/>
<br/> The -f flag enables a user with 'admin' privilege to delete the spec
<br/> or set the 'last modified' date. By default, specs can be deleted
<br/> only by their owner.
<br/>
<br/> A branch spec can also be used to expose the internally generated
<br/> mapping of a stream to its parent. (See 'p4 help stream' and 'p4
<br/> help streamintro'.)
<br/>
<br/> The -S stream flag will expose the internally generated mapping.
<br/> The -P flag may be used with -S to treat the stream as if it were a
<br/> child of a different parent. The -o flag is required with -S.
<br/>
<br/>
</remarks>
<example>
To create a branch spec [-i]:
<code>
BranchSpec newBranchSpec = new BranchSpec();
newBranchSpec.Id = "newBranchSpec";
newBranchSpec.Owner = "admin";
newBranchSpec.Description = " created by perforce";
newBranchSpec.ViewMap = new ViewMap();
string v0 = "//depot/main/... //depot/rel1/...";
string v1 = "//depot/main/... //depot/rel2/...";
string v2 = "//depot/dev/... //depot/main/...";
newBranchSpec.ViewMap.Add(v0);
newBranchSpec.ViewMap.Add(v1);
newBranchSpec.ViewMap.Add(v2);
Options opts = new Options(BranchSpecCmdFlags.Input);
_repository.CreateBranchSpec(newBranchSpec, opts);
</code>
</example>
<seealso cref="T:Perforce.P4.BranchSpecCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.CreateBranchSpec(Perforce.P4.BranchSpec)">
<summary>
Create a new branch in the repository.
</summary>
<param name="branch">Branch specification for the new branch</param>
<returns>The Branch object if new branch was created, null if creation failed</returns>
<example>
To create a basic branch spec:
<code>
BranchSpec newBranchSpec = new BranchSpec();
newBranchSpec.Id = "newBranchSpec";
newBranchSpec.ViewMap = new ViewMap();
string v0 = "//depot/main/... //depot/rel1/...";
newBranchSpec.ViewMap.Add(v0);
_repository.CreateBranchSpec(newBranchSpec);
</code>
</example>
</member>
<member name="M:Perforce.P4.Repository.UpdateBranchSpec(Perforce.P4.BranchSpec)">
<summary>
Update the record for a branch in the repository
</summary>
<param name="branch">Branch specification for the branch being updated</param>
<returns>The Branch object if new depot was saved, null if creation failed</returns>
<example>
To append a view to an existing branch spec:
<code>
BranchSpec updateBranchSpec = _repository.GetBranchSpec("newBranchSpec");
string v0 = "\"//depot/main/a file with spaces.txt\" \"//depot/rel1/a file with spaces.txt\"";
updateBranchSpec.ViewMap.Add(v0);
_repository.UpdateBranchSpec(updateBranchSpec);
</code>
To lock a branch spec:
<code>
BranchSpec updateBranchSpec = _repository.GetBranchSpec("newBranchSpec");
updateBranchSpec.Locked = true;
_repository.UpdateBranchSpec(updateBranchSpec);
</code>
</example>
</member>
<member name="M:Perforce.P4.Repository.GetBranchSpec(System.String,System.String,System.String,Perforce.P4.Options)">
<summary>
Get the record for an existing branch from the repository.
</summary>
<param name="branch">Branch name</param>
<returns>The Branch object if branch was found, null if creation failed</returns>
<example>
To get a branch spec:
<code>
BranchSpec getBranchSpec = _repository.GetBranchSpec("newBranchSpec");
</code>
</example>
</member>
<member name="M:Perforce.P4.Repository.GetBranchSpecs(Perforce.P4.Options)">
<summary>
Get a list of branches from the repository
</summary>
<returns>A list containing the matching branches</returns>
<remarks>
<br/><b>p4 help branches</b>
<br/>
<br/> branches -- Display list of branch specifications
<br/>
<br/> p4 branches [-t] [-u user] [[-e|-E] nameFilter -m max]
<br/>
<br/> Lists branch specifications. (See 'p4 help branch'.)
<br/>
<br/> The -t flag displays the time as well as the date.
<br/>
<br/> The -u user flag lists branch specs owned by the specified user.
<br/>
<br/> The -e nameFilter flag lists branch specs with a name that matches
<br/> the nameFilter pattern, for example: -e 'svr-dev-rel*'. The -e flag
<br/> uses the server's normal case-sensitivity rules. The -E flag makes
<br/> the matching case-insensitive, even on a case-sensitive server.
<br/>
<br/> The -m max flag limits output to the specified number of branch specs.
<br/>
<br/>
</remarks>
<example>
To get all branches and include timestamps [-t] (WARNING, will fetch all branches from the repository):
<code>
Options opts = new Options(BranchSpecsCmdFlags.Time, "", "", -1);
IList<Branch> branches = _repository.GetBranchSpecs(opts);
</code>
To get branches owned by 'Bob' [-u]:
<code>
Options opts = new Options(BranchSpecsCmdFlags.None, "Bob", "", -1);
IList<Branch> branches = _repository.GetBranchSpecs(opts);
</code>
To get the first 10 branches that start with the capital letter 'A' [-m] [-e]:
<code>
Options opts = new Options(BranchSpecsCmdFlags.None, "", "A*", 10);
IList<Branch> branches = _repository.GetBranchSpecs(opts);
</code>
To get the first 10 branches that start with the letter 'A' case insensitive [-m] [-E]:
<code>
Options opts = new Options(BranchSpecsCmdFlags.IgnoreCase, "", "A*", 10);
IList<Branch> branches = _repository.GetBranchSpecs(opts);
</code>
</example>
<seealso cref="T:Perforce.P4.BranchSpecsCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.DeleteBranchSpec(Perforce.P4.BranchSpec,Perforce.P4.Options)">
<summary>
Delete a branch from the repository
</summary>
<param name="branch">The branch to be deleted</param>
<param name="options">The '-f' and '-d' flags are valid when deleting an
existing branch</param>
<example>
To delete a branch spec owned by you [-d implied]:
<code>
BranchSpec deleteBranchSpec = new BranchSpec();
deleteBranchSpec.Id = "newBranchSpec";
_repository.DeleteBranchSpec(deleteBranchSpec, null);
</code>
To delete a branch owned by someone other than you [-d implied] [-f requires admin privileges]:
<code>
BranchSpec deleteBranchSpec = new BranchSpec();
deleteBranchSpec.Id = "newBranchSpec";
Options opts = new Options(BranchSpecsCmdFlags.Force);
_repository.DeleteBranchSpec(deleteBranchSpec, opts);
</code>
</example>
<seealso cref="T:Perforce.P4.BranchSpecCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.GetClientMetadata">
<summary>
Get client application information.
</summary>
<returns>Information avout a connection's client-side application context.</returns>
<remarks>
<br/>
<br/><b>p4 help info</b>
<br/>
<br/> info -- Display client/server information
<br/>
<br/> p4 info [-s]
<br/>
<br/> Info lists information about the current client (user name,
<br/> client name, applicable client root, client current directory,
<br/> and the client IP address) and some server information (server
<br/> IP address, server root, date, uptime, version and license data).
<br/>
<br/> The -s option produces 'short' output that omits any information
<br/> that requires a database lookup such as the client root).
<br/>
<br/>
</remarks>
<example>
To get the current client host name:
<code>
ClientMetadata c = rep.GetClientMetadata();
string machinename = c.HostName;
</code>
</example>
</member>
<member name="M:Perforce.P4.Repository.CreateJob(Perforce.P4.Job,Perforce.P4.Options)">
<summary>
Create a new job in the repository.
</summary>
<param name="job">Job specification for the new job</param>
<param name="options">The '-i' flags is needed when creating a new job</param>
<returns>The Job object if new job was created, null if creation failed</returns>
<remarks> The '-i' flags is added if not specified by the caller
<br/>
<br/><b>p4 help job</b>
<br/>
<br/> job -- Create or edit a job (defect) specification
<br/>
<br/> p4 job [-f] [jobName]
<br/> p4 job -d jobName
<br/> p4 job -o [jobName]
<br/> p4 job -i [-f]
<br/>
<br/> The 'p4 job' command creates and edits job specifications using an
<br/> ASCII form. A job is a defect, enhancement, or other unit of
<br/> intended work.The 'p4 fix' command associates changelists with jobs.
<br/>
<br/> With no arguments, 'p4 job' creates an empty job specification
<br/> and invokes the user's editor. When the specification is saved,
<br/> a job name of the form jobNNNNNN is assigned. If the jobName
<br/> parameter is specified on the command line, the job is created or
<br/> opened for editing.
<br/>
<br/> As jobs are entered or updated, all fields are indexed for searching
<br/> Text fields are broken into individual alphanumeric words (punctuation
<br/> and whitespace are ignored) and each word is case-folded and entered
<br/> into the word index. Date fields are converted to an internal
<br/> representation (seconds since 1970/01/01 00:00:00) and entered
<br/> into the date index.
<br/>
<br/> The fields that compose a job are defined by the 'p4 jobspec' command.
<br/> Perforce provides a default job specification that you can edit.
<br/>
<br/> The -d flag deletes the specified job. You cannot delete a job if
<br/> it has pending or submitted fixes associated with it.
<br/>
<br/> The -o flag writes the job specification to the standard output.
<br/> The user's editor is not invoked.
<br/>
<br/> The -i flag reads a job specification from the standard input. The
<br/> user's editor is not invoked.
<br/>
<br/> The -f flag enables you set fields that are read-only by default.
<br/> The -f flag requires 'admin' access, which is granted using the
<br/> 'p4 protect' command.
<br/>
<br/>
</remarks>
<example>
To create a new job with a name 'Myjob':
<code>
Job job = new Job();
job.Id = "Myjob";
job.Add("Status", "open");
job.Add("User", "admin");
job.Add("Description", "this is a test job");
Job job = _repository.CreateJob( job, null);
</code>
To create a job with name of the form jobNNNNNN:
<code>
Job job = new Job();
job.Id = "new";
job.Add("Status", "open");
job.Add("User", "admin");
job.Add("Description", "this is a test job");
Job job = _repository.CreateJob( job, JobCmdFlags.Input);
</code>
</example>
<seealso cref="T:Perforce.P4.JobCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.CreateJob(Perforce.P4.Job)">
<summary>
Create a new job in the repository.
</summary>
<param name="job">Job specification for the new job</param>
<returns>The Job object if new job was created, null if creation failed</returns>
<example>
To create a new job name of the form jobNNNNNN:
<code>
Job job = new Job();
job.Id = new;
job.Add("Status", "open");
job.Add("User", "admin");
job.Add("Description", "this is a test job");
Job job = _repository.CreateJob( job );
</code>
</example>
</member>
<member name="M:Perforce.P4.Repository.UpdateJob(Perforce.P4.Job)">
<summary>
Update the record for a job in the repository
</summary>
<param name="job">Job specification for the job being updated</param>
<returns>The Job object if new job was saved, null if creation failed</returns>
<example>
To update the description of job 'job000001':
<code>
Job job = _repository.GetJob("job000001");
job["Description"] += "\n\Updated description";
_repository.UpdateJob("job000001");
</code>
</example>
</member>
<member name="M:Perforce.P4.Repository.GetJob(System.String,Perforce.P4.Options)">
<summary>
Get the record for an existing job from the repository.
</summary>
<param name="job">Job name</param>
<param name="options">There are no valid flags to use when fetching an existing job</param>
<returns>The Job object if new job was found, null if the requested job does not exist</returns>
<example>
Get the record for job 'job000001':
<code>
Job job = _repository.GetJob("job000001", null);
</code>
</example>
</member>
<member name="M:Perforce.P4.Repository.GetJob(System.String)">
<summary>
Get the record for an existing job from the repository.
</summary>
<param name="job">Job name</param>
<returns>The Job object if new job was found, null if the requested job does not exist</returns>
<example>
Get the record for job 'job000001':
<code>
Job job = _repository.GetJob("job000001");
</code>
</example>
</member>
<member name="M:Perforce.P4.Repository.GetJobs(Perforce.P4.Options,Perforce.P4.FileSpec[])">
<summary>
Get a list of jobs from the repository
</summary>
<param name="options">options for the jobs command<see cref="!:JobsOptions"/></param>
<returns>A list containing the matching jobs</returns>
<remarks>
<br/><b>p4 help jobs</b>
<br/>
<br/> jobs -- Display list of jobs
<br/>
<br/> p4 jobs [-e jobview -i -l -m max -r] [file[revRange] ...]
<br/> p4 jobs -R
<br/>
<br/> Lists jobs in the server. If a file specification is included, fixes
<br/> for submitted changelists affecting the specified files are listed.
<br/> The file specification can include wildcards and a revision range.
<br/> See 'p4 help revisions' for details about specifying revisions.
<br/>
<br/> The -e flag lists jobs matching the expression specified in the
<br/> jobview parameter. For a description of jobview syntax, see 'p4 help
<br/> jobview'.
<br/>
<br/> The -i flag includes any fixes made by changelists integrated into
<br/> the specified files.
<br/>
<br/> The -l flag produces long output with the full text of the job
<br/> descriptions.
<br/>
<br/> The -m max flag limits the output to the first 'max' jobs, ordered
<br/> by their job name.
<br/>
<br/> The -r flag sorts the jobs in reverse order (by job name).
<br/>
<br/> The -R flag rebuilds the jobs table and reindexes each job, which
<br/> is necessary after upgrading to 98.2. 'p4 jobs -R' requires that the
<br/> user be an operator or have 'super' access granted by 'p4 protect'.
<br/>
<br/>
</remarks>
<example>
To get a list of 100 jobs that include files under a given filepath:
<code>
FileSpec path = new FileSpec(new DepotPath(@"//depot/..."), null);
IList<Job> jobs = rep.GetJobs((new Options(JobsCmdFlags.LongDescriptions, null, 100)), path);
</code>
To get a list of 100 jobs with the status "open":
<code>
string jobView = "status=open";
IList<Job> jobs = rep.GetJobs((new Options(JobsCmdFlags.LongDescriptions, jobView, 100)), path);
</code>
To get a list of 10 jobs in reverse order:
<code>
IList<Job> jobs = rep.GetJobs((new Options(JobsCmdFlags.ReverseSort, null, 10));
</code>
To get a list of 10 jobs that include any fixes made by changelists integrated into
the specified files:
<code>
FileSpec path = new FileSpec(new DepotPath(@"//depot/..."), null);
IList<Job> jobs = rep.GetJobs((new Options(JobsCmdFlags.IncludeIntegratedFixes, null, 10)), path);
</code>
</example>
<seealso cref="T:Perforce.P4.JobsCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.DeleteJob(Perforce.P4.Job,Perforce.P4.Options)">
<summary>
Delete a job from the repository
</summary>
<param name="job">The job to be deleted</param>
<param name="options">Only the '-f' flag is valid when deleting an existing job</param>
<example>
To delete job000002 from the repository :
<code>
Job u = _repository.GetJob("job000002");
_repository.DeleteJob(u, null);
</code>
</example>
</member>
<member name="M:Perforce.P4.Repository.CreateDepot(Perforce.P4.Depot,Perforce.P4.Options)">
<summary>
Create a new depot in the repository.
</summary>
<param name="depot">Depot specification for the new depot</param>
<param name="options">The '-i' flag is required when creating a new depot</param>
<returns>The Depot object if new depot was created, null if creation failed</returns>
<remarks> The '-i' flag is added if not specified by the caller
<br/>
<br/><b>p4 help depot</b>
<br/>
<br/> depot -- Create or edit a depot specification
<br/>
<br/> p4 depot name
<br/> p4 depot -d [-f] name
<br/> p4 depot -o name
<br/> p4 depot -i
<br/>
<br/> Create a new depot specification or edit an existing depot
<br/> specification. The specification form is put into a temporary file
<br/> and the editor (configured by the environment variable $P4EDITOR)
<br/> is invoked.
<br/>
<br/> The depot specification contains the following fields:
<br/>
<br/> Depot: The name of the depot. This name cannot be the same as
<br/> any branch, client, or label name.
<br/>
<br/> Owner: The user who created this depot.
<br/>
<br/> Date: The date that this specification was last modified.
<br/>
<br/> Description: A short description of the depot (optional).
<br/>
<br/> Type: One of the types: 'local', 'stream', 'remote', 'spec',
<br/> 'archive', or 'unload'.
<br/>
<br/> A 'local' depot (the default) is managed directly by
<br/> the server and its files reside in the server's root
<br/> directory.
<br/>
<br/> A 'stream' depot is a local depot dedicated to the
<br/> storage of files in a stream.
<br/>
<br/> A 'remote' depot refers to files in another Perforce
<br/> server.
<br/>
<br/> A 'spec' depot automatically archives all edited forms
<br/> (branch, change, client, depot, group, job, jobspec,
<br/> protect, triggers, typemap, and user) in special,
<br/> read-only files. The files are named:
<br/> //depotname/formtype/name[suffix]. Updates to jobs made
<br/> by the 'p4 change', 'p4 fix', and 'p4 submit' commands
<br/> are also saved, but other automatic updates such as
<br/> as access times or opened files (for changes) are not.
<br/> A server can contain only one 'spec' depot.
<br/>
<br/> A 'archive' depot defines a storage location to which
<br/> obsolete revisions may be relocated.
<br/>
<br/> An 'unload' depot defines a storage location to which
<br/> database records may be unloaded and from which they
<br/> may be reloaded.
<br/>
<br/> Address: For remote depots, the $P4PORT (connection address)
<br/> of the remote server.
<br/>
<br/> Suffix: For spec depots, the optional suffix to be used
<br/> for generated paths. The default is '.p4s'.
<br/>
<br/> Map: Path translation information, in the form of a file
<br/> pattern with a single ... in it. For local depots,
<br/> this path is relative to the server's root directory
<br/> or to server.depot.root if it has been configured
<br/> (Example: depot/...). For remote depots, this path
<br/> refers to the remote server's namespace
<br/> (Example: //depot/...).
<br/>
<br/> SpecMap: For spec depots, the optional description of which
<br/> specs should be saved, as one or more patterns.
<br/>
<br/> The -d flag deletes the specified depot. If any files reside in the
<br/> depot, they must be removed with 'p4 obliterate' before deleting the
<br/> depot. If any archive files remain in the depot directory, they may
<br/> be referenced by lazy copies in other depots; use 'p4 snap' to break
<br/> those linkages. Snap lazy copies prior to obliterating the old depot
<br/> files to allow the obliterate command to remove any unreferenced
<br/> archives from the depot directory. If the depot directory is not
<br/> empty, you must specify the -f flag to delete the depot.
<br/>
<br/> The -o flag writes the depot specification to standard output. The
<br/> user's editor is not invoked.
<br/>
<br/> The -i flag reads a depot specification from standard input. The
<br/> user's editor is not invoked.
<br/>
<br/>
</remarks>
<example>
To create a streams depot named MobileApp:
<code>
Depot d = new Depot();
d.Id = "MobileApp";
d.Description = "Stream depot for mobile app project";
d.Owner = "admin";
d.Type = DepotType.Stream;
d.Map = "MobileApp/...";
Depot MobileApp = Repository.CreateDepot(d, null);
</code>
</example>
<seealso cref="T:Perforce.P4.DepotCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.CreateDepot(Perforce.P4.Depot)">
<summary>
Create a new depot in the repository.
</summary>
<param name="depot">Depot specification for the new depot</param>
<returns>The Depot object if new depot was created, null if creation failed</returns>
<remarks> The '-i' flag is added if not specified by the caller
<br/>
<br/><b>p4 help depot</b>
<br/>
<br/> depot -- Create or edit a depot specification
<br/>
<br/> p4 depot name
<br/> p4 depot -d [-f] name
<br/> p4 depot -o name
<br/> p4 depot -i
<br/>
<br/> Create a new depot specification or edit an existing depot
<br/> specification. The specification form is put into a temporary file
<br/> and the editor (configured by the environment variable $P4EDITOR)
<br/> is invoked.
<br/>
<br/> The depot specification contains the following fields:
<br/>
<br/> Depot: The name of the depot. This name cannot be the same as
<br/> any branch, client, or label name.
<br/>
<br/> Owner: The user who created this depot.
<br/>
<br/> Date: The date that this specification was last modified.
<br/>
<br/> Description: A short description of the depot (optional).
<br/>
<br/> Type: One of the types: 'local', 'stream', 'remote', 'spec',
<br/> 'archive', or 'unload'.
<br/>
<br/> A 'local' depot (the default) is managed directly by
<br/> the server and its files reside in the server's root
<br/> directory.
<br/>
<br/> A 'stream' depot is a local depot dedicated to the
<br/> storage of files in a stream.
<br/>
<br/> A 'remote' depot refers to files in another Perforce
<br/> server.
<br/>
<br/> A 'spec' depot automatically archives all edited forms
<br/> (branch, change, client, depot, group, job, jobspec,
<br/> protect, triggers, typemap, and user) in special,
<br/> read-only files. The files are named:
<br/> //depotname/formtype/name[suffix]. Updates to jobs made
<br/> by the 'p4 change', 'p4 fix', and 'p4 submit' commands
<br/> are also saved, but other automatic updates such as
<br/> as access times or opened files (for changes) are not.
<br/> A server can contain only one 'spec' depot.
<br/>
<br/> A 'archive' depot defines a storage location to which
<br/> obsolete revisions may be relocated.
<br/>
<br/> An 'unload' depot defines a storage location to which
<br/> database records may be unloaded and from which they
<br/> may be reloaded.
<br/>
<br/> Address: For remote depots, the $P4PORT (connection address)
<br/> of the remote server.
<br/>
<br/> Suffix: For spec depots, the optional suffix to be used
<br/> for generated paths. The default is '.p4s'.
<br/>
<br/> Map: Path translation information, in the form of a file
<br/> pattern with a single ... in it. For local depots,
<br/> this path is relative to the server's root directory
<br/> or to server.depot.root if it has been configured
<br/> (Example: depot/...). For remote depots, this path
<br/> refers to the remote server's namespace
<br/> (Example: //depot/...).
<br/>
<br/> SpecMap: For spec depots, the optional description of which
<br/> specs should be saved, as one or more patterns.
<br/>
<br/> The -d flag deletes the specified depot. If any files reside in the
<br/> depot, they must be removed with 'p4 obliterate' before deleting the
<br/> depot. If any archive files remain in the depot directory, they may
<br/> be referenced by lazy copies in other depots; use 'p4 snap' to break
<br/> those linkages. Snap lazy copies prior to obliterating the old depot
<br/> files to allow the obliterate command to remove any unreferenced
<br/> archives from the depot directory. If the depot directory is not
<br/> empty, you must specify the -f flag to delete the depot.
<br/>
<br/> The -o flag writes the depot specification to standard output. The
<br/> user's editor is not invoked.
<br/>
<br/> The -i flag reads a depot specification from standard input. The
<br/> user's editor is not invoked.
<br/>
<br/>
</remarks>
<example>
To create a streams depot named MobileApp:
<code>
Depot d = new Depot();
d.Id = "MobileApp";
d.Description = "Stream depot for mobile app project";
d.Owner = "admin";
d.Type = DepotType.Stream;
d.Map = "MobileApp/...";
Depot MobileApp = Repository.CreateDepot(d);
</code>
</example>
</member>
<member name="M:Perforce.P4.Repository.UpdateDepot(Perforce.P4.Depot)">
<summary>
Update the record for a depot in the repository
</summary>
<param name="depot">Depot specification for the depot being updated</param>
<returns>The Depot object if new depot was saved, null if creation failed</returns>
<remarks> The '-i' flag is added if not specified by the caller
<br/>
<br/><b>p4 help depot</b>
<br/>
<br/> depot -- Create or edit a depot specification
<br/>
<br/> p4 depot name
<br/> p4 depot -d [-f] name
<br/> p4 depot -o name
<br/> p4 depot -i
<br/>
<br/> Create a new depot specification or edit an existing depot
<br/> specification. The specification form is put into a temporary file
<br/> and the editor (configured by the environment variable $P4EDITOR)
<br/> is invoked.
<br/>
<br/> The depot specification contains the following fields:
<br/>
<br/> Depot: The name of the depot. This name cannot be the same as
<br/> any branch, client, or label name.
<br/>
<br/> Owner: The user who created this depot.
<br/>
<br/> Date: The date that this specification was last modified.
<br/>
<br/> Description: A short description of the depot (optional).
<br/>
<br/> Type: One of the types: 'local', 'stream', 'remote', 'spec',
<br/> 'archive', or 'unload'.
<br/>
<br/> A 'local' depot (the default) is managed directly by
<br/> the server and its files reside in the server's root
<br/> directory.
<br/>
<br/> A 'stream' depot is a local depot dedicated to the
<br/> storage of files in a stream.
<br/>
<br/> A 'remote' depot refers to files in another Perforce
<br/> server.
<br/>
<br/> A 'spec' depot automatically archives all edited forms
<br/> (branch, change, client, depot, group, job, jobspec,
<br/> protect, triggers, typemap, and user) in special,
<br/> read-only files. The files are named:
<br/> //depotname/formtype/name[suffix]. Updates to jobs made
<br/> by the 'p4 change', 'p4 fix', and 'p4 submit' commands
<br/> are also saved, but other automatic updates such as
<br/> as access times or opened files (for changes) are not.
<br/> A server can contain only one 'spec' depot.
<br/>
<br/> A 'archive' depot defines a storage location to which
<br/> obsolete revisions may be relocated.
<br/>
<br/> An 'unload' depot defines a storage location to which
<br/> database records may be unloaded and from which they
<br/> may be reloaded.
<br/>
<br/> Address: For remote depots, the $P4PORT (connection address)
<br/> of the remote server.
<br/>
<br/> Suffix: For spec depots, the optional suffix to be used
<br/> for generated paths. The default is '.p4s'.
<br/>
<br/> Map: Path translation information, in the form of a file
<br/> pattern with a single ... in it. For local depots,
<br/> this path is relative to the server's root directory
<br/> or to server.depot.root if it has been configured
<br/> (Example: depot/...). For remote depots, this path
<br/> refers to the remote server's namespace
<br/> (Example: //depot/...).
<br/>
<br/> SpecMap: For spec depots, the optional description of which
<br/> specs should be saved, as one or more patterns.
<br/>
<br/> The -d flag deletes the specified depot. If any files reside in the
<br/> depot, they must be removed with 'p4 obliterate' before deleting the
<br/> depot. If any archive files remain in the depot directory, they may
<br/> be referenced by lazy copies in other depots; use 'p4 snap' to break
<br/> those linkages. Snap lazy copies prior to obliterating the old depot
<br/> files to allow the obliterate command to remove any unreferenced
<br/> archives from the depot directory. If the depot directory is not
<br/> empty, you must specify the -f flag to delete the depot.
<br/>
<br/> The -o flag writes the depot specification to standard output. The
<br/> user's editor is not invoked.
<br/>
<br/> The -i flag reads a depot specification from standard input. The
<br/> user's editor is not invoked.
<br/>
<br/>
</remarks>
<example>
To update the streams depot named MobileApp:
<code>
Depot d = Repository.GetDepot("MobileApp");
// change description
d.Description = "Stream depot for Win8 phone apps";
Depot MobileApp = Repository.UpdateDepot(d);
</code>
</example>
</member>
<member name="M:Perforce.P4.Repository.GetDepot(System.String,Perforce.P4.Options)">
<summary>
Get the record for an existing depot from the repository.
</summary>
<param name="depot">Depot name</param>
<param name="options">There are no valid flags to use when fetching an existing depot</param>
<returns>The Depot object if depot was found, null if not</returns>
<remarks>
<br/>
<br/><b>p4 help depot</b>
<br/>
<br/> depot -- Create or edit a depot specification
<br/>
<br/> p4 depot name
<br/> p4 depot -d [-f] name
<br/> p4 depot -o name
<br/> p4 depot -i
<br/>
<br/> Create a new depot specification or edit an existing depot
<br/> specification. The specification form is put into a temporary file
<br/> and the editor (configured by the environment variable $P4EDITOR)
<br/> is invoked.
<br/>
<br/> The depot specification contains the following fields:
<br/>
<br/> Depot: The name of the depot. This name cannot be the same as
<br/> any branch, client, or label name.
<br/>
<br/> Owner: The user who created this depot.
<br/>
<br/> Date: The date that this specification was last modified.
<br/>
<br/> Description: A short description of the depot (optional).
<br/>
<br/> Type: One of the types: 'local', 'stream', 'remote', 'spec',
<br/> 'archive', or 'unload'.
<br/>
<br/> A 'local' depot (the default) is managed directly by
<br/> the server and its files reside in the server's root
<br/> directory.
<br/>
<br/> A 'stream' depot is a local depot dedicated to the
<br/> storage of files in a stream.
<br/>
<br/> A 'remote' depot refers to files in another Perforce
<br/> server.
<br/>
<br/> A 'spec' depot automatically archives all edited forms
<br/> (branch, change, client, depot, group, job, jobspec,
<br/> protect, triggers, typemap, and user) in special,
<br/> read-only files. The files are named:
<br/> //depotname/formtype/name[suffix]. Updates to jobs made
<br/> by the 'p4 change', 'p4 fix', and 'p4 submit' commands
<br/> are also saved, but other automatic updates such as
<br/> as access times or opened files (for changes) are not.
<br/> A server can contain only one 'spec' depot.
<br/>
<br/> A 'archive' depot defines a storage location to which
<br/> obsolete revisions may be relocated.
<br/>
<br/> An 'unload' depot defines a storage location to which
<br/> database records may be unloaded and from which they
<br/> may be reloaded.
<br/>
<br/> Address: For remote depots, the $P4PORT (connection address)
<br/> of the remote server.
<br/>
<br/> Suffix: For spec depots, the optional suffix to be used
<br/> for generated paths. The default is '.p4s'.
<br/>
<br/> Map: Path translation information, in the form of a file
<br/> pattern with a single ... in it. For local depots,
<br/> this path is relative to the server's root directory
<br/> or to server.depot.root if it has been configured
<br/> (Example: depot/...). For remote depots, this path
<br/> refers to the remote server's namespace
<br/> (Example: //depot/...).
<br/>
<br/> SpecMap: For spec depots, the optional description of which
<br/> specs should be saved, as one or more patterns.
<br/>
<br/> The -d flag deletes the specified depot. If any files reside in the
<br/> depot, they must be removed with 'p4 obliterate' before deleting the
<br/> depot. If any archive files remain in the depot directory, they may
<br/> be referenced by lazy copies in other depots; use 'p4 snap' to break
<br/> those linkages. Snap lazy copies prior to obliterating the old depot
<br/> files to allow the obliterate command to remove any unreferenced
<br/> archives from the depot directory. If the depot directory is not
<br/> empty, you must specify the -f flag to delete the depot.
<br/>
<br/> The -o flag writes the depot specification to standard output. The
<br/> user's editor is not invoked.
<br/>
<br/> The -i flag reads a depot specification from standard input. The
<br/> user's editor is not invoked.
<br/>
<br/>
</remarks>
<example>
To get the spec for a streams depot named MobileApp:
<code>
Depot MobileApp = Repository.GetDepot("MobileApp", null);
</code>
</example>
<seealso cref="T:Perforce.P4.DepotCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.GetDepot(System.String)">
<summary>
Get the record for an existing depot from the repository.
</summary>
<param name="depot">Depot name</param>
<returns>The Depot object if depot was found, null if not</returns>
<remarks>
<br/>
<br/><b>p4 help depot</b>
<br/>
<br/> depot -- Create or edit a depot specification
<br/>
<br/> p4 depot name
<br/> p4 depot -d [-f] name
<br/> p4 depot -o name
<br/> p4 depot -i
<br/>
<br/> Create a new depot specification or edit an existing depot
<br/> specification. The specification form is put into a temporary file
<br/> and the editor (configured by the environment variable $P4EDITOR)
<br/> is invoked.
<br/>
<br/> The depot specification contains the following fields:
<br/>
<br/> Depot: The name of the depot. This name cannot be the same as
<br/> any branch, client, or label name.
<br/>
<br/> Owner: The user who created this depot.
<br/>
<br/> Date: The date that this specification was last modified.
<br/>
<br/> Description: A short description of the depot (optional).
<br/>
<br/> Type: One of the types: 'local', 'stream', 'remote', 'spec',
<br/> 'archive', or 'unload'.
<br/>
<br/> A 'local' depot (the default) is managed directly by
<br/> the server and its files reside in the server's root
<br/> directory.
<br/>
<br/> A 'stream' depot is a local depot dedicated to the
<br/> storage of files in a stream.
<br/>
<br/> A 'remote' depot refers to files in another Perforce
<br/> server.
<br/>
<br/> A 'spec' depot automatically archives all edited forms
<br/> (branch, change, client, depot, group, job, jobspec,
<br/> protect, triggers, typemap, and user) in special,
<br/> read-only files. The files are named:
<br/> //depotname/formtype/name[suffix]. Updates to jobs made
<br/> by the 'p4 change', 'p4 fix', and 'p4 submit' commands
<br/> are also saved, but other automatic updates such as
<br/> as access times or opened files (for changes) are not.
<br/> A server can contain only one 'spec' depot.
<br/>
<br/> A 'archive' depot defines a storage location to which
<br/> obsolete revisions may be relocated.
<br/>
<br/> An 'unload' depot defines a storage location to which
<br/> database records may be unloaded and from which they
<br/> may be reloaded.
<br/>
<br/> Address: For remote depots, the $P4PORT (connection address)
<br/> of the remote server.
<br/>
<br/> Suffix: For spec depots, the optional suffix to be used
<br/> for generated paths. The default is '.p4s'.
<br/>
<br/> Map: Path translation information, in the form of a file
<br/> pattern with a single ... in it. For local depots,
<br/> this path is relative to the server's root directory
<br/> or to server.depot.root if it has been configured
<br/> (Example: depot/...). For remote depots, this path
<br/> refers to the remote server's namespace
<br/> (Example: //depot/...).
<br/>
<br/> SpecMap: For spec depots, the optional description of which
<br/> specs should be saved, as one or more patterns.
<br/>
<br/> The -d flag deletes the specified depot. If any files reside in the
<br/> depot, they must be removed with 'p4 obliterate' before deleting the
<br/> depot. If any archive files remain in the depot directory, they may
<br/> be referenced by lazy copies in other depots; use 'p4 snap' to break
<br/> those linkages. Snap lazy copies prior to obliterating the old depot
<br/> files to allow the obliterate command to remove any unreferenced
<br/> archives from the depot directory. If the depot directory is not
<br/> empty, you must specify the -f flag to delete the depot.
<br/>
<br/> The -o flag writes the depot specification to standard output. The
<br/> user's editor is not invoked.
<br/>
<br/> The -i flag reads a depot specification from standard input. The
<br/> user's editor is not invoked.
<br/>
<br/>
</remarks>
<example>
To get the spec for a streams depot named MobileApp:
<code>
Depot MobileApp = Repository.GetDepot("MobileApp");
</code>
</example>
<seealso cref="T:Perforce.P4.DepotCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.GetDepots">
<summary>
Get a list of depots from the repository
</summary>
<returns>A list containing the matching depots</returns>
<remarks>
<br/><b>p4 help depots</b>
<br/>
<br/> depots -- Lists defined depots
<br/>
<br/> p4 depots
<br/>
<br/> Lists all depots defined in the server.
<br/> Depots takes no arguments.
<br/>
<br/>
</remarks>
<example>
To list the depots on the server:
<code>
IList<Depot> depots = Repository.GetDepots();
</code>
</example>
</member>
<member name="M:Perforce.P4.Repository.DeleteDepot(Perforce.P4.Depot,Perforce.P4.Options)">
<summary>
Delete a depot from the repository
</summary>
<param name="depot">The depot to be deleted</param>
<param name="options">Only the '-d' flag is valid when deleting an existing depot</param>
<remarks>
<br/>
<br/><b>p4 help depot</b>
<br/>
<br/> depot -- Create or edit a depot specification
<br/>
<br/> p4 depot name
<br/> p4 depot -d [-f] name
<br/> p4 depot -o name
<br/> p4 depot -i
<br/>
<br/> Create a new depot specification or edit an existing depot
<br/> specification. The specification form is put into a temporary file
<br/> and the editor (configured by the environment variable $P4EDITOR)
<br/> is invoked.
<br/>
<br/> The depot specification contains the following fields:
<br/>
<br/> Depot: The name of the depot. This name cannot be the same as
<br/> any branch, client, or label name.
<br/>
<br/> Owner: The user who created this depot.
<br/>
<br/> Date: The date that this specification was last modified.
<br/>
<br/> Description: A short description of the depot (optional).
<br/>
<br/> Type: One of the types: 'local', 'stream', 'remote', 'spec',
<br/> 'archive', or 'unload'.
<br/>
<br/> A 'local' depot (the default) is managed directly by
<br/> the server and its files reside in the server's root
<br/> directory.
<br/>
<br/> A 'stream' depot is a local depot dedicated to the
<br/> storage of files in a stream.
<br/>
<br/> A 'remote' depot refers to files in another Perforce
<br/> server.
<br/>
<br/> A 'spec' depot automatically archives all edited forms
<br/> (branch, change, client, depot, group, job, jobspec,
<br/> protect, triggers, typemap, and user) in special,
<br/> read-only files. The files are named:
<br/> //depotname/formtype/name[suffix]. Updates to jobs made
<br/> by the 'p4 change', 'p4 fix', and 'p4 submit' commands
<br/> are also saved, but other automatic updates such as
<br/> as access times or opened files (for changes) are not.
<br/> A server can contain only one 'spec' depot.
<br/>
<br/> A 'archive' depot defines a storage location to which
<br/> obsolete revisions may be relocated.
<br/>
<br/> An 'unload' depot defines a storage location to which
<br/> database records may be unloaded and from which they
<br/> may be reloaded.
<br/>
<br/> Address: For remote depots, the $P4PORT (connection address)
<br/> of the remote server.
<br/>
<br/> Suffix: For spec depots, the optional suffix to be used
<br/> for generated paths. The default is '.p4s'.
<br/>
<br/> Map: Path translation information, in the form of a file
<br/> pattern with a single ... in it. For local depots,
<br/> this path is relative to the server's root directory
<br/> or to server.depot.root if it has been configured
<br/> (Example: depot/...). For remote depots, this path
<br/> refers to the remote server's namespace
<br/> (Example: //depot/...).
<br/>
<br/> SpecMap: For spec depots, the optional description of which
<br/> specs should be saved, as one or more patterns.
<br/>
<br/> The -d flag deletes the specified depot. If any files reside in the
<br/> depot, they must be removed with 'p4 obliterate' before deleting the
<br/> depot. If any archive files remain in the depot directory, they may
<br/> be referenced by lazy copies in other depots; use 'p4 snap' to break
<br/> those linkages. Snap lazy copies prior to obliterating the old depot
<br/> files to allow the obliterate command to remove any unreferenced
<br/> archives from the depot directory. If the depot directory is not
<br/> empty, you must specify the -f flag to delete the depot.
<br/>
<br/> The -o flag writes the depot specification to standard output. The
<br/> user's editor is not invoked.
<br/>
<br/> The -i flag reads a depot specification from standard input. The
<br/> user's editor is not invoked.
<br/>
<br/>
</remarks>
<example>
To delete a streams depot named MobileApp:
<code>
Depot d = Repository.GetDepot("MobileApp");
Repository.DeleteDepot(d, null);
</code>
</example>
<seealso cref="T:Perforce.P4.DepotCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.CreateGroup(Perforce.P4.Group,Perforce.P4.Options)">
<summary>
Create a new group in the repository.
</summary>
<param name="group">Group specification for the new group</param>
<param name="options">The '-i' flags are required when creating a new group</param>
<returns>The Group object if new group was created, null if creation failed</returns>
<remarks> The '-i' flag is added if not specified by the caller
<br/>
<br/><b>p4 help group</b>
<br/>
<br/> group -- Change members of user group
<br/>
<br/> p4 group [-a|-A] name
<br/> p4 group -d [-a] name
<br/> p4 group -o name
<br/> p4 group -i [-a|-A]
<br/>
<br/> Create a group or modify the membership of an existing group.
<br/> A group can contain users and other groups. The group specification
<br/> is put into a temporary file and the editor (configured by the
<br/> environment variable $P4EDITOR) is invoked.
<br/>
<br/> A group exists when it has any users or other groups in it, and
<br/> ceases to exist if all users and groups in it are removed.
<br/>
<br/> Each group has MaxResults, MaxScanRows, and MaxLockTime fields,
<br/> which limit the resources committed to operations performed by
<br/> members of the group. For these fields, 'unlimited' or 'unset'
<br/> means no limit for that group. An individual user's limit is the
<br/> highest of any group with a limit to which he belongs, unlimited if
<br/> any of his groups has 'unlimited' for that field, or unlimited
<br/> if he belongs to no group with a limit. See 'p4 help maxresults'
<br/> for more information on MaxResults, MaxScanRows and MaxLockTime.
<br/>
<br/> Each group also has a Timeout field, which specifies how long (in
<br/> seconds) a 'p4 login' ticket remains valid. A value of 'unset' or
<br/> 'unlimited' is equivalent to no timeout. An individual's timeout is
<br/> the highest of any group with a limit to which he belongs, unlimited
<br/> if any of his groups has 'unlimited' for the timeout value, or
<br/> unlimited if he belongs to no group with a limit. See 'p4 help login'
<br/> for more information.
<br/>
<br/> Each group has a PasswordTimeout field, which determines how long a
<br/> password remains valid for members of the group.
<br/>
<br/> A group may be synchronized with an LDAP group by setting the three
<br/> fields: LdapConfig, LdapSearchQuery and LdapUserAttribute. This takes
<br/> the LDAP configuration (see 'p4 ldap') specified by LdapConfig and uses
<br/> it to execute the query stored by LdapSearchQuery. The LDAP attribute
<br/> specified by LdapUserAttribute is taken to be user's username and is
<br/> added to the group's user list. At least one group owner must be set if
<br/> these LDAP fields are used. If the LDAP server requires login for
<br/> read-only queries, then the LDAP configuration must contain valid bind
<br/> credentials in the LDAP spec's SearchBindDN and SearchPasswd fields
<br/>
<br/> The -d flag deletes a group.
<br/>
<br/> The -o flag writes the group specification to standard output. The
<br/> user's editor is not invoked.
<br/>
<br/> The -i flag reads a group specification from standard input. The
<br/> user's editor is not invoked. The new group specification replaces
<br/> the previous one.
<br/>
<br/> The -a flag enables a user without 'super' access to modify the group
<br/> if that user is an 'owner' of that group. Group owners are specified
<br/> in the 'Owners' field of the group spec.
<br/>
<br/> The -A flag enables a user with 'admin' access to add a new group.
<br/> Existing groups may not be modified when this flag is used.
<br/>
<br/> All commands that require access granted by 'p4 protect' consider a
<br/> user's groups when calculating access levels.
<br/>
<br/> 'p4 group' requires 'super' access granted by 'p4 protect' unless
<br/> invoked with the '-a' or '-A' flag by a qualified user.
<br/>
<br/>
</remarks>
<example>
To create the group 'Mygroup' with the owner 'Bob' and a user 'Ted'
when connected as super user:
<code>
string targetGroup = "Mygroup";
Group group = new Group();
group.Id = targetGroup;
group.UserNames = new List<string> { "Ted" };
group.OwnerNames = new List<string> { "Bob" };
_repository.CreateGroup(group, null);
</code>
To create a group "everyone" when connected as a user with admin level
rights:
<code>
string targetGroup = "everyone";
Group group = new Group();
group.Id = targetGroup;
group.UserNames = new List<string> { "Ted" };
group.OwnerNames = new List<string> { "Bob" };
_repository.CreateGroup(group, new Options(GroupCmdFlags.AdminAdd));
</code>
</example>
<seealso cref="T:Perforce.P4.GroupCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.CreateGroup(Perforce.P4.Group)">
<summary>
Create a new group in the repository.
</summary>
<param name="group">Group specification for the new group</param>
<returns>The Group object if new group was created, null if creation failed</returns>
<example>
To create the group 'Mygroup' with the owner 'Bob' and a users 'Ted' and 'Alex':
<code>
string targetGroup = "Mygroup";
Group group = new Group();
group.Id = targetGroup;
group.UserNames = new List<string> { "Ted", "Alex" };
group.OwnerNames = new List<string> { "Bob" };
_repository.CreateGroup(group);
</code>
</example>
</member>
<member name="M:Perforce.P4.Repository.UpdateGroup(Perforce.P4.Group)">
<summary>
Update the record for a group in the repository
</summary>
<param name="group">Group specification for the group being updated</param>
<returns>The Group object if new group was saved, null if creation failed</returns>
<example>
To add the user 'Carol' to the group 'Mygroup':
<code>
string targetGroup = "Mygroup";
Group group = GetGroup(targetGroup, null);
group.UserNames.Add("Carol");
_repository.UpdateGroup(group);
</code>
</example>
</member>
<member name="M:Perforce.P4.Repository.UpdateGroup(Perforce.P4.Group,Perforce.P4.Options)">
<summary>
Update the record for a group in the repository
</summary>
<param name="group">Group specification for the group being updated</param>
<returns>The Group object if new group was saved, null if creation failed</returns>
<example>
To add the user 'Carol' to the group 'Mygroup':
<code>
string targetGroup = "Mygroup";
Group group = GetGroup(targetGroup, null);
group.UserNames.Add("Carol");
_repository.UpdateGroup(group);
</code>
</example>
</member>
<member name="M:Perforce.P4.Repository.GetGroup(System.String,Perforce.P4.Options)">
<summary>
Get the record for an existing group from the repository.
</summary>
<param name="group">Group name</param>
<param name="options">The Owner Access flag (-a) needs to be used if a user
without 'super' access is an 'owner' of that group.</param>
<returns>The Group object if new group was found, null if creation failed</returns>
<example>
To get the group 'everyone' when connected as a user with super access:
<code>
string targetGroup = "everyone";
Group group = _repository.GetGroup(targetGroup, null);
</code>
To get the group 'Mygroup' when connected as a without super access
who is the owner of that group:
<code>
string targetGroup = "everyone";
GroupCmdOptions opts = new GroupCmdOptions(GroupCmdFlags.OwnerAccess);
Group group = _repository.GetGroup(targetGroup, opts);
</code>
</example>
<seealso cref="T:Perforce.P4.GroupCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.GetGroup(System.String)">
<summary>
Get the record for an existing group from the repository.
</summary>
<param name="group">Group name</param>
<returns>The Group object if new group was found, null if creation failed</returns>
<example>
To get the group 'everyone':
<code>
string targetGroup = "everyone";
IList<Group> group = _repository.getGroup(targetGroup);
</code>
</example>
</member>
<member name="M:Perforce.P4.Repository.GetGroups(Perforce.P4.Options,System.String[])">
<summary>
Get a list of groups from the repository
</summary>
<param name="options">options for the groups command<see cref="T:Perforce.P4.GroupsCmdOptions"/></param>
<returns>A list containing the matching groups</returns>
<remarks>
<br/><b>p4 help groups</b>
<br/>
<br/> groups -- List groups (of users)
<br/>
<br/> p4 groups [-m max] [-v] [group]
<br/> p4 groups [-m max] [-i [-v]] user | group
<br/> p4 groups [-m max] [-g | -u | -o] name
<br/>
<br/> The first form lists all user groups defined in the server, or just
<br/> the specified group.
<br/>
<br/> The second form displays subgroup relationships. If a user argument is
<br/> specified, only groups containing that user are displayed. If a group
<br/> argument is specified, only groups containing the group are displayed.
<br/>
<br/> The third form is useful when there are groups and users with the
<br/> same name, or when requesting all groups owned by a certain user.
<br/>
<br/> The -i flag also displays groups that the user or group belongs to
<br/> indirectly by means of membership in subgroups.
<br/>
<br/> The -m max flag limits output to the specified number of groups.
<br/>
<br/> The -v flag displays the MaxResults, MaxScanRows, MaxLockTime, and
<br/> Timeout values for each group that is displayed.
<br/>
<br/> The -g flag indicates that the 'name' argument is a group.
<br/>
<br/> The -u flag indicates that the 'name' argument is a user.
<br/>
<br/> The -o flag indicates that the 'name' argument is an owner.
<br/>
<br/>
</remarks>
<example>
To get the first 10 groups:
<code>
Options opts = new Options(GroupsCmdFlags.None, 10);
IList<Group> groups = _repository.getGroups(opts);
</code>
To get all groups that 'Bob' belongs to, including subgroups:
<code>
Options opts = new Options(GroupsCmdFlags.IncludeIndirect, -1);
IList<Group> groups = _repository.getGroups(opts, "Bob");
</code>
To get all the groups with the MaxResults, MaxScanRows, MaxLockTime, and
Timeout values for the specified group:
<code>
Options opts = new Options(GroupsCmdFlags.IncludeAllValues, -1);
IList<Group> groups = _repository.getGroups(opts);
</code>
</example>
<seealso cref="T:Perforce.P4.GroupsCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.DeleteGroup(Perforce.P4.Group,Perforce.P4.Options)">
<summary>
Delete a group from the repository
</summary>
<param name="group">The group to be deleted</param>
<param name="options">The -a flag is needed to delete
a group when the user is an owner but not a superuser</param>
<example>
To delete the group 'Mygroup' when the user is a superuser:
<code>
string targetGroup = "Mygroup";
Group group = new Group();
group.Id = targetGroup;
_repository.DeleteGroup(group, null);
</code>
To delete the group 'Mygroup' when the user is an owner but not a superuser:
<code>
string targetGroup = "Mygroup";
Group group = new _repository.GetGroup(targetGroup);
GroupCmdOptions opts = new GroupCmdOptions(GroupCmdFlags.OwnerAccess);
_repository.DeleteGroup(group, opts);
</code>
</example>
<seealso cref="T:Perforce.P4.GroupCmdFlags"/>
</member>
<!-- Badly formed XML comment ignored for member "M:Perforce.P4.Repository.NewChangelist" -->
<member name="M:Perforce.P4.Repository.CreateChangelist(Perforce.P4.Changelist,Perforce.P4.Options)">
<summary>
Create a new changelist in the repository.
</summary>
<param name="change">Changelist specification for the new changelist</param>
<param name="options">'-s', '-f', -u flags are valid when creating a new changelist</param>
<returns>The Changelist object if new user was created, null if creation failed</returns>
<remarks> The '-i' flag is added if not specified by the caller
<br/>
<br/><b>p4 help change</b>
<br/>
<br/> change -- Create or edit a changelist description
<br/> changelist -- synonym for 'change'
<br/>
<br/> p4 change [-s] [-f | -u] [[-O] changelist#]
<br/> p4 change -d [-f -s -O] changelist#
<br/> p4 change -o [-s] [-f] [[-O] changelist#]
<br/> p4 change -i [-s] [-f | -u]
<br/> p4 change -t restricted | public [-U user] [-f | -u | -O] changelist#
<br/> p4 change -U user [-t restricted | public] [-f] changelist#
<br/>
<br/> 'p4 change' creates and edits changelists and their descriptions.
<br/> With no argument, 'p4 change' creates a new changelist. If a
<br/> changelist number is specified, 'p4 change' edits an existing
<br/> pending changelist. In both cases, the changelist specification
<br/> is placed into a form and the user's editor is invoked.
<br/>
<br/> The -d flag deletes a pending changelist, if it has no opened files
<br/> and no pending fixes associated with it. Use 'p4 opened -a' to
<br/> report on opened files and 'p4 reopen' to move them to another
<br/> changelist. Use 'p4 fixes -c changelist#' to report on pending
<br/> fixes and 'p4 fix -d -c changelist# jobs...' to delete pending
<br/> fixes. The changelist can be deleted only by the user and client
<br/> who created it, or by a user with 'admin' privilege using the -f
<br/> flag.
<br/>
<br/> The -o flag writes the changelist specification to the standard
<br/> output. The user's editor is not invoked.
<br/>
<br/> The -i flag reads a changelist specification from the standard
<br/> input. The user's editor is not invoked.
<br/>
<br/> The -f flag forces the update or deletion of other users' pending
<br/> changelists. -f can also force the deletion of submitted changelists
<br/> after they have been emptied of files using 'p4 obliterate'. By
<br/> default, submitted changelists cannot be changed. The -f flag can
<br/> also force display of the 'Description' field in a restricted
<br/> changelist. Finally the -f flag can force changing the 'User' of
<br/> an empty pending change via -U. The -f flag requires 'admin'
<br/> access granted by 'p4 protect'. The -f and -u flags are mutually
<br/> exclusive.
<br/>
<br/> The -u flag can force the update of a submitted change by the owner
<br/> of the change. Only the Jobs, Type, and Description fields can be
<br/> changed using the -u flag. The -f and -u flags cannot be used in
<br/> the same change command.
<br/>
<br/> The -s flag extends the list of jobs to include the fix status
<br/> for each job. On new changelists, the fix status begins as the
<br/> special status 'ignore', which, if left unchanged simply excludes
<br/> the job from those being fixed. Otherwise, the fix status, like
<br/> that applied with 'p4 fix -s', becomes the job's status when
<br/> the changelist is committed. Note that this option exists
<br/> to support integration with external defect trackers.
<br/>
<br/> The -O flag specifies that the changelist number is the original
<br/> number of a changelist which was renamed on submit.
<br/>
<br/> The -U flag changes the 'User' of an empty pending change to the
<br/> specified user. The user field can only be changed using this flag
<br/> by the user who created the change, or by a user with 'admin'
<br/> privilege using the -f flag. This option is useful for running
<br/> in a trigger or script.
<br/>
<br/> The -t flag changes the 'Type' of the change to 'restricted'
<br/> or 'public' without displaying the change form. This option is
<br/> useful for running in a trigger or script.
<br/>
<br/> The 'Type' field can be used to hide the change or its description
<br/> from users. Valid values for this field are 'public' (default), and
<br/> 'restricted'. A shelved or committed change that is 'restricted' is
<br/> accessible only to users who own the change or have 'list' permission
<br/> to at least one file in the change. A pending (not shelved)
<br/> restricted change is only accessible to its owner. Public changes
<br/> are accessible to all users. This setting affects the output of the
<br/> 'p4 change', 'p4 changes', and 'p4 describe' commands. Note that
<br/> the '-S' flag is required with 'p4 describe' for the command to
<br/> enforce shelved rather than pending restricted changelist rules.
<br/>
<br/> If a user is not permitted to have access to a restricted change,
<br/> The 'Description' text is replaced with a 'no permission' message
<br/> (see 'Type' field). Users with admin permission can override the
<br/> restriction using the -f flag.
<br/>
<br/>
</remarks>
<example>
To create a new changelist:
<code>
Changelist c = new Changelist();
c = Repository.CreateChangelist(c, null);
</code>
To create a new restricted changelist:
<code>
Changelist c = new Changelist();
c.Type = ChangeListType.Restricted;
c = Repository.CreateChangelist(c, null);
</code>
</example>
<seealso cref="T:Perforce.P4.ChangeCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.CreateChangelist(Perforce.P4.Changelist)">
<summary>
Create a new change in the repository.
</summary>
<param name="change">Changelist specification for the new change</param>
<returns>The Changelist object if new change was created, null if creation failed</returns>
<remarks>
<br/>
<br/><b>p4 help change</b>
<br/>
<br/> change -- Create or edit a changelist description
<br/> changelist -- synonym for 'change'
<br/>
<br/> p4 change [-s] [-f | -u] [[-O] changelist#]
<br/> p4 change -d [-f -s -O] changelist#
<br/> p4 change -o [-s] [-f] [[-O] changelist#]
<br/> p4 change -i [-s] [-f | -u]
<br/> p4 change -t restricted | public [-U user] [-f | -u | -O] changelist#
<br/> p4 change -U user [-t restricted | public] [-f] changelist#
<br/>
<br/> 'p4 change' creates and edits changelists and their descriptions.
<br/> With no argument, 'p4 change' creates a new changelist. If a
<br/> changelist number is specified, 'p4 change' edits an existing
<br/> pending changelist. In both cases, the changelist specification
<br/> is placed into a form and the user's editor is invoked.
<br/>
<br/> The -d flag deletes a pending changelist, if it has no opened files
<br/> and no pending fixes associated with it. Use 'p4 opened -a' to
<br/> report on opened files and 'p4 reopen' to move them to another
<br/> changelist. Use 'p4 fixes -c changelist#' to report on pending
<br/> fixes and 'p4 fix -d -c changelist# jobs...' to delete pending
<br/> fixes. The changelist can be deleted only by the user and client
<br/> who created it, or by a user with 'admin' privilege using the -f
<br/> flag.
<br/>
<br/> The -o flag writes the changelist specification to the standard
<br/> output. The user's editor is not invoked.
<br/>
<br/> The -i flag reads a changelist specification from the standard
<br/> input. The user's editor is not invoked.
<br/>
<br/> The -f flag forces the update or deletion of other users' pending
<br/> changelists. -f can also force the deletion of submitted changelists
<br/> after they have been emptied of files using 'p4 obliterate'. By
<br/> default, submitted changelists cannot be changed. The -f flag can
<br/> also force display of the 'Description' field in a restricted
<br/> changelist. Finally the -f flag can force changing the 'User' of
<br/> an empty pending change via -U. The -f flag requires 'admin'
<br/> access granted by 'p4 protect'. The -f and -u flags are mutually
<br/> exclusive.
<br/>
<br/> The -u flag can force the update of a submitted change by the owner
<br/> of the change. Only the Jobs, Type, and Description fields can be
<br/> changed using the -u flag. The -f and -u flags cannot be used in
<br/> the same change command.
<br/>
<br/> The -s flag extends the list of jobs to include the fix status
<br/> for each job. On new changelists, the fix status begins as the
<br/> special status 'ignore', which, if left unchanged simply excludes
<br/> the job from those being fixed. Otherwise, the fix status, like
<br/> that applied with 'p4 fix -s', becomes the job's status when
<br/> the changelist is committed. Note that this option exists
<br/> to support integration with external defect trackers.
<br/>
<br/> The -O flag specifies that the changelist number is the original
<br/> number of a changelist which was renamed on submit.
<br/>
<br/> The -U flag changes the 'User' of an empty pending change to the
<br/> specified user. The user field can only be changed using this flag
<br/> by the user who created the change, or by a user with 'admin'
<br/> privilege using the -f flag. This option is useful for running
<br/> in a trigger or script.
<br/>
<br/> The -t flag changes the 'Type' of the change to 'restricted'
<br/> or 'public' without displaying the change form. This option is
<br/> useful for running in a trigger or script.
<br/>
<br/> The 'Type' field can be used to hide the change or its description
<br/> from users. Valid values for this field are 'public' (default), and
<br/> 'restricted'. A shelved or committed change that is 'restricted' is
<br/> accessible only to users who own the change or have 'list' permission
<br/> to at least one file in the change. A pending (not shelved)
<br/> restricted change is only accessible to its owner. Public changes
<br/> are accessible to all users. This setting affects the output of the
<br/> 'p4 change', 'p4 changes', and 'p4 describe' commands. Note that
<br/> the '-S' flag is required with 'p4 describe' for the command to
<br/> enforce shelved rather than pending restricted changelist rules.
<br/>
<br/> If a user is not permitted to have access to a restricted change,
<br/> The 'Description' text is replaced with a 'no permission' message
<br/> (see 'Type' field). Users with admin permission can override the
<br/> restriction using the -f flag.
<br/>
<br/>
</remarks>
<example>
To create a new changelist:
<code>
Changelist c = new Changelist();
c = Repository.CreateChangelist(c, null);
</code>
</example>
</member>
<member name="M:Perforce.P4.Repository.UpdateChangelist(Perforce.P4.Changelist)">
<summary>
Update the record for a change in the repository
</summary>
<param name="change">Changelist specification for the change being updated</param>
<returns>The Changelist object if new change was saved, null if creation failed</returns>
<remarks>
<br/>
<br/><b>p4 help change</b>
<br/>
<br/> change -- Create or edit a changelist description
<br/> changelist -- synonym for 'change'
<br/>
<br/> p4 change [-s] [-f | -u] [[-O] changelist#]
<br/> p4 change -d [-f -s -O] changelist#
<br/> p4 change -o [-s] [-f] [[-O] changelist#]
<br/> p4 change -i [-s] [-f | -u]
<br/> p4 change -t restricted | public [-U user] [-f | -u | -O] changelist#
<br/> p4 change -U user [-t restricted | public] [-f] changelist#
<br/>
<br/> 'p4 change' creates and edits changelists and their descriptions.
<br/> With no argument, 'p4 change' creates a new changelist. If a
<br/> changelist number is specified, 'p4 change' edits an existing
<br/> pending changelist. In both cases, the changelist specification
<br/> is placed into a form and the user's editor is invoked.
<br/>
<br/> The -d flag deletes a pending changelist, if it has no opened files
<br/> and no pending fixes associated with it. Use 'p4 opened -a' to
<br/> report on opened files and 'p4 reopen' to move them to another
<br/> changelist. Use 'p4 fixes -c changelist#' to report on pending
<br/> fixes and 'p4 fix -d -c changelist# jobs...' to delete pending
<br/> fixes. The changelist can be deleted only by the user and client
<br/> who created it, or by a user with 'admin' privilege using the -f
<br/> flag.
<br/>
<br/> The -o flag writes the changelist specification to the standard
<br/> output. The user's editor is not invoked.
<br/>
<br/> The -i flag reads a changelist specification from the standard
<br/> input. The user's editor is not invoked.
<br/>
<br/> The -f flag forces the update or deletion of other users' pending
<br/> changelists. -f can also force the deletion of submitted changelists
<br/> after they have been emptied of files using 'p4 obliterate'. By
<br/> default, submitted changelists cannot be changed. The -f flag can
<br/> also force display of the 'Description' field in a restricted
<br/> changelist. Finally the -f flag can force changing the 'User' of
<br/> an empty pending change via -U. The -f flag requires 'admin'
<br/> access granted by 'p4 protect'. The -f and -u flags are mutually
<br/> exclusive.
<br/>
<br/> The -u flag can force the update of a submitted change by the owner
<br/> of the change. Only the Jobs, Type, and Description fields can be
<br/> changed using the -u flag. The -f and -u flags cannot be used in
<br/> the same change command.
<br/>
<br/> The -s flag extends the list of jobs to include the fix status
<br/> for each job. On new changelists, the fix status begins as the
<br/> special status 'ignore', which, if left unchanged simply excludes
<br/> the job from those being fixed. Otherwise, the fix status, like
<br/> that applied with 'p4 fix -s', becomes the job's status when
<br/> the changelist is committed. Note that this option exists
<br/> to support integration with external defect trackers.
<br/>
<br/> The -O flag specifies that the changelist number is the original
<br/> number of a changelist which was renamed on submit.
<br/>
<br/> The -U flag changes the 'User' of an empty pending change to the
<br/> specified user. The user field can only be changed using this flag
<br/> by the user who created the change, or by a user with 'admin'
<br/> privilege using the -f flag. This option is useful for running
<br/> in a trigger or script.
<br/>
<br/> The -t flag changes the 'Type' of the change to 'restricted'
<br/> or 'public' without displaying the change form. This option is
<br/> useful for running in a trigger or script.
<br/>
<br/> The 'Type' field can be used to hide the change or its description
<br/> from users. Valid values for this field are 'public' (default), and
<br/> 'restricted'. A shelved or committed change that is 'restricted' is
<br/> accessible only to users who own the change or have 'list' permission
<br/> to at least one file in the change. A pending (not shelved)
<br/> restricted change is only accessible to its owner. Public changes
<br/> are accessible to all users. This setting affects the output of the
<br/> 'p4 change', 'p4 changes', and 'p4 describe' commands. Note that
<br/> the '-S' flag is required with 'p4 describe' for the command to
<br/> enforce shelved rather than pending restricted changelist rules.
<br/>
<br/> If a user is not permitted to have access to a restricted change,
<br/> The 'Description' text is replaced with a 'no permission' message
<br/> (see 'Type' field). Users with admin permission can override the
<br/> restriction using the -f flag.
<br/>
<br/>
</remarks>
<example>
To update changelist 15:
<code>
Changelist c = Repository.GetChangelist(15);
// change the description
c.Description = "fixes for localization";
c = Repository.UpdateChangelist(c);
</code>
</example>
</member>
<member name="M:Perforce.P4.Repository.UpdateChangelist(Perforce.P4.Changelist,Perforce.P4.Options)">
<summary>
Update the record for a change in the repository
</summary>
<param name="change">Changelist specification for the change being updated</param>
<returns>The Changelist object if new change was saved, null if creation failed</returns>
<remarks>
<br/>
<br/><b>p4 help change</b>
<br/>
<br/> change -- Create or edit a changelist description
<br/> changelist -- synonym for 'change'
<br/>
<br/> p4 change [-s] [-f | -u] [[-O] changelist#]
<br/> p4 change -d [-f -s -O] changelist#
<br/> p4 change -o [-s] [-f] [[-O] changelist#]
<br/> p4 change -i [-s] [-f | -u]
<br/> p4 change -t restricted | public [-U user] [-f | -u | -O] changelist#
<br/> p4 change -U user [-t restricted | public] [-f] changelist#
<br/>
<br/> 'p4 change' creates and edits changelists and their descriptions.
<br/> With no argument, 'p4 change' creates a new changelist. If a
<br/> changelist number is specified, 'p4 change' edits an existing
<br/> pending changelist. In both cases, the changelist specification
<br/> is placed into a form and the user's editor is invoked.
<br/>
<br/> The -d flag deletes a pending changelist, if it has no opened files
<br/> and no pending fixes associated with it. Use 'p4 opened -a' to
<br/> report on opened files and 'p4 reopen' to move them to another
<br/> changelist. Use 'p4 fixes -c changelist#' to report on pending
<br/> fixes and 'p4 fix -d -c changelist# jobs...' to delete pending
<br/> fixes. The changelist can be deleted only by the user and client
<br/> who created it, or by a user with 'admin' privilege using the -f
<br/> flag.
<br/>
<br/> The -o flag writes the changelist specification to the standard
<br/> output. The user's editor is not invoked.
<br/>
<br/> The -i flag reads a changelist specification from the standard
<br/> input. The user's editor is not invoked.
<br/>
<br/> The -f flag forces the update or deletion of other users' pending
<br/> changelists. -f can also force the deletion of submitted changelists
<br/> after they have been emptied of files using 'p4 obliterate'. By
<br/> default, submitted changelists cannot be changed. The -f flag can
<br/> also force display of the 'Description' field in a restricted
<br/> changelist. Finally the -f flag can force changing the 'User' of
<br/> an empty pending change via -U. The -f flag requires 'admin'
<br/> access granted by 'p4 protect'. The -f and -u flags are mutually
<br/> exclusive.
<br/>
<br/> The -u flag can force the update of a submitted change by the owner
<br/> of the change. Only the Jobs, Type, and Description fields can be
<br/> changed using the -u flag. The -f and -u flags cannot be used in
<br/> the same change command.
<br/>
<br/> The -s flag extends the list of jobs to include the fix status
<br/> for each job. On new changelists, the fix status begins as the
<br/> special status 'ignore', which, if left unchanged simply excludes
<br/> the job from those being fixed. Otherwise, the fix status, like
<br/> that applied with 'p4 fix -s', becomes the job's status when
<br/> the changelist is committed. Note that this option exists
<br/> to support integration with external defect trackers.
<br/>
<br/> The -O flag specifies that the changelist number is the original
<br/> number of a changelist which was renamed on submit.
<br/>
<br/> The -U flag changes the 'User' of an empty pending change to the
<br/> specified user. The user field can only be changed using this flag
<br/> by the user who created the change, or by a user with 'admin'
<br/> privilege using the -f flag. This option is useful for running
<br/> in a trigger or script.
<br/>
<br/> The -t flag changes the 'Type' of the change to 'restricted'
<br/> or 'public' without displaying the change form. This option is
<br/> useful for running in a trigger or script.
<br/>
<br/> The 'Type' field can be used to hide the change or its description
<br/> from users. Valid values for this field are 'public' (default), and
<br/> 'restricted'. A shelved or committed change that is 'restricted' is
<br/> accessible only to users who own the change or have 'list' permission
<br/> to at least one file in the change. A pending (not shelved)
<br/> restricted change is only accessible to its owner. Public changes
<br/> are accessible to all users. This setting affects the output of the
<br/> 'p4 change', 'p4 changes', and 'p4 describe' commands. Note that
<br/> the '-S' flag is required with 'p4 describe' for the command to
<br/> enforce shelved rather than pending restricted changelist rules.
<br/>
<br/> If a user is not permitted to have access to a restricted change,
<br/> The 'Description' text is replaced with a 'no permission' message
<br/> (see 'Type' field). Users with admin permission can override the
<br/> restriction using the -f flag.
<br/>
<br/>
</remarks>
<example>
To update changelist 15:
<code>
Changelist c = Repository.GetChangelist(15);
// change the description
c.Description = "fixes for localization";
c = Repository.UpdateChangelist(c);
</code>
To update changelist 15 as an admin user, changing type to Public:
<code>
Changelist c = Repository.GetChangelist(15);
ChangeCmdOptions opts =
new ChangeCmdOptions(ChangeCmdFlags.Force);
c.Type = ChangeListType.Public;
c = Repository.UpdateChangelist(c, opts);
</code>
</example>
<seealso cref="T:Perforce.P4.ChangeCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.UpdateSubmittedChangelist(Perforce.P4.Changelist)">
<summary>
Update the record for a submitted change in the repository
</summary>
<param name="change">Changelist specification for the change being updated</param>
<param name="options">options for updating an existing change</param>
<returns>The Changelist object if new change was saved, null if creation failed</returns>
<summary>
Update the record for a change in the repository
</summary>
<param name="change">Changelist specification for the change being updated</param>
<returns>The Changelist object if new change was saved, null if creation failed</returns>
<remarks>
<br/>
<br/><b>p4 help change</b>
<br/>
<br/> change -- Create or edit a changelist description
<br/> changelist -- synonym for 'change'
<br/>
<br/> p4 change [-s] [-f | -u] [[-O] changelist#]
<br/> p4 change -d [-f -s -O] changelist#
<br/> p4 change -o [-s] [-f] [[-O] changelist#]
<br/> p4 change -i [-s] [-f | -u]
<br/> p4 change -t restricted | public [-U user] [-f | -u | -O] changelist#
<br/> p4 change -U user [-t restricted | public] [-f] changelist#
<br/>
<br/> 'p4 change' creates and edits changelists and their descriptions.
<br/> With no argument, 'p4 change' creates a new changelist. If a
<br/> changelist number is specified, 'p4 change' edits an existing
<br/> pending changelist. In both cases, the changelist specification
<br/> is placed into a form and the user's editor is invoked.
<br/>
<br/> The -d flag deletes a pending changelist, if it has no opened files
<br/> and no pending fixes associated with it. Use 'p4 opened -a' to
<br/> report on opened files and 'p4 reopen' to move them to another
<br/> changelist. Use 'p4 fixes -c changelist#' to report on pending
<br/> fixes and 'p4 fix -d -c changelist# jobs...' to delete pending
<br/> fixes. The changelist can be deleted only by the user and client
<br/> who created it, or by a user with 'admin' privilege using the -f
<br/> flag.
<br/>
<br/> The -o flag writes the changelist specification to the standard
<br/> output. The user's editor is not invoked.
<br/>
<br/> The -i flag reads a changelist specification from the standard
<br/> input. The user's editor is not invoked.
<br/>
<br/> The -f flag forces the update or deletion of other users' pending
<br/> changelists. -f can also force the deletion of submitted changelists
<br/> after they have been emptied of files using 'p4 obliterate'. By
<br/> default, submitted changelists cannot be changed. The -f flag can
<br/> also force display of the 'Description' field in a restricted
<br/> changelist. Finally the -f flag can force changing the 'User' of
<br/> an empty pending change via -U. The -f flag requires 'admin'
<br/> access granted by 'p4 protect'. The -f and -u flags are mutually
<br/> exclusive.
<br/>
<br/> The -u flag can force the update of a submitted change by the owner
<br/> of the change. Only the Jobs, Type, and Description fields can be
<br/> changed using the -u flag. The -f and -u flags cannot be used in
<br/> the same change command.
<br/>
<br/> The -s flag extends the list of jobs to include the fix status
<br/> for each job. On new changelists, the fix status begins as the
<br/> special status 'ignore', which, if left unchanged simply excludes
<br/> the job from those being fixed. Otherwise, the fix status, like
<br/> that applied with 'p4 fix -s', becomes the job's status when
<br/> the changelist is committed. Note that this option exists
<br/> to support integration with external defect trackers.
<br/>
<br/> The -O flag specifies that the changelist number is the original
<br/> number of a changelist which was renamed on submit.
<br/>
<br/> The -U flag changes the 'User' of an empty pending change to the
<br/> specified user. The user field can only be changed using this flag
<br/> by the user who created the change, or by a user with 'admin'
<br/> privilege using the -f flag. This option is useful for running
<br/> in a trigger or script.
<br/>
<br/> The -t flag changes the 'Type' of the change to 'restricted'
<br/> or 'public' without displaying the change form. This option is
<br/> useful for running in a trigger or script.
<br/>
<br/> The 'Type' field can be used to hide the change or its description
<br/> from users. Valid values for this field are 'public' (default), and
<br/> 'restricted'. A shelved or committed change that is 'restricted' is
<br/> accessible only to users who own the change or have 'list' permission
<br/> to at least one file in the change. A pending (not shelved)
<br/> restricted change is only accessible to its owner. Public changes
<br/> are accessible to all users. This setting affects the output of the
<br/> 'p4 change', 'p4 changes', and 'p4 describe' commands. Note that
<br/> the '-S' flag is required with 'p4 describe' for the command to
<br/> enforce shelved rather than pending restricted changelist rules.
<br/>
<br/> If a user is not permitted to have access to a restricted change,
<br/> The 'Description' text is replaced with a 'no permission' message
<br/> (see 'Type' field). Users with admin permission can override the
<br/> restriction using the -f flag.
<br/>
<br/>
</remarks>
<example>
To update changelist 25:
<code>
Changelist c = Repository.GetChangelist(25);
// change the description
c.Description = "fixes for localization";
c = Repository.UpdateSubmittedChangelist(c);
</code>
</example>
</member>
<member name="M:Perforce.P4.Repository.UpdateSubmittedChangelist(Perforce.P4.Changelist,Perforce.P4.Options)">
<summary>
Update the record for a submitted change in the repository
</summary>
<param name="change">Changelist specification for the change being updated</param>
<param name="options">options for the submitted change being updated</param>
<returns>The Changelist object if new change was saved, null if creation failed</returns>
<remarks>
<br/>
<br/><b>p4 help change</b>
<br/>
<br/> change -- Create or edit a changelist description
<br/> changelist -- synonym for 'change'
<br/>
<br/> p4 change [-s] [-f | -u] [[-O] changelist#]
<br/> p4 change -d [-f -s -O] changelist#
<br/> p4 change -o [-s] [-f] [[-O] changelist#]
<br/> p4 change -i [-s] [-f | -u]
<br/> p4 change -t restricted | public [-U user] [-f | -u | -O] changelist#
<br/> p4 change -U user [-t restricted | public] [-f] changelist#
<br/>
<br/> 'p4 change' creates and edits changelists and their descriptions.
<br/> With no argument, 'p4 change' creates a new changelist. If a
<br/> changelist number is specified, 'p4 change' edits an existing
<br/> pending changelist. In both cases, the changelist specification
<br/> is placed into a form and the user's editor is invoked.
<br/>
<br/> The -d flag deletes a pending changelist, if it has no opened files
<br/> and no pending fixes associated with it. Use 'p4 opened -a' to
<br/> report on opened files and 'p4 reopen' to move them to another
<br/> changelist. Use 'p4 fixes -c changelist#' to report on pending
<br/> fixes and 'p4 fix -d -c changelist# jobs...' to delete pending
<br/> fixes. The changelist can be deleted only by the user and client
<br/> who created it, or by a user with 'admin' privilege using the -f
<br/> flag.
<br/>
<br/> The -o flag writes the changelist specification to the standard
<br/> output. The user's editor is not invoked.
<br/>
<br/> The -i flag reads a changelist specification from the standard
<br/> input. The user's editor is not invoked.
<br/>
<br/> The -f flag forces the update or deletion of other users' pending
<br/> changelists. -f can also force the deletion of submitted changelists
<br/> after they have been emptied of files using 'p4 obliterate'. By
<br/> default, submitted changelists cannot be changed. The -f flag can
<br/> also force display of the 'Description' field in a restricted
<br/> changelist. Finally the -f flag can force changing the 'User' of
<br/> an empty pending change via -U. The -f flag requires 'admin'
<br/> access granted by 'p4 protect'. The -f and -u flags are mutually
<br/> exclusive.
<br/>
<br/> The -u flag can force the update of a submitted change by the owner
<br/> of the change. Only the Jobs, Type, and Description fields can be
<br/> changed using the -u flag. The -f and -u flags cannot be used in
<br/> the same change command.
<br/>
<br/> The -s flag extends the list of jobs to include the fix status
<br/> for each job. On new changelists, the fix status begins as the
<br/> special status 'ignore', which, if left unchanged simply excludes
<br/> the job from those being fixed. Otherwise, the fix status, like
<br/> that applied with 'p4 fix -s', becomes the job's status when
<br/> the changelist is committed. Note that this option exists
<br/> to support integration with external defect trackers.
<br/>
<br/> The -O flag specifies that the changelist number is the original
<br/> number of a changelist which was renamed on submit.
<br/>
<br/> The -U flag changes the 'User' of an empty pending change to the
<br/> specified user. The user field can only be changed using this flag
<br/> by the user who created the change, or by a user with 'admin'
<br/> privilege using the -f flag. This option is useful for running
<br/> in a trigger or script.
<br/>
<br/> The -t flag changes the 'Type' of the change to 'restricted'
<br/> or 'public' without displaying the change form. This option is
<br/> useful for running in a trigger or script.
<br/>
<br/> The 'Type' field can be used to hide the change or its description
<br/> from users. Valid values for this field are 'public' (default), and
<br/> 'restricted'. A shelved or committed change that is 'restricted' is
<br/> accessible only to users who own the change or have 'list' permission
<br/> to at least one file in the change. A pending (not shelved)
<br/> restricted change is only accessible to its owner. Public changes
<br/> are accessible to all users. This setting affects the output of the
<br/> 'p4 change', 'p4 changes', and 'p4 describe' commands. Note that
<br/> the '-S' flag is required with 'p4 describe' for the command to
<br/> enforce shelved rather than pending restricted changelist rules.
<br/>
<br/> If a user is not permitted to have access to a restricted change,
<br/> The 'Description' text is replaced with a 'no permission' message
<br/> (see 'Type' field). Users with admin permission can override the
<br/> restriction using the -f flag.
<br/>
<br/>
</remarks>
<example>
To update changelist 25:
<code>
Changelist c = Repository.GetChangelist(25);
// change the description
c.Description = "fixes for localization";
c = Repository.UpdateChangelist(c);
</code>
To update changelist 15 as an admin user, changing type to Public:
<code>
Changelist c = Repository.GetChangelist(25);
ChangeCmdOptions opts =
new ChangeCmdOptions(ChangeCmdFlags.Force);
c.Type = ChangeListType.Public;
c = Repository.UpdateChangelist(c, opts);
</code>
</example>
<seealso cref="T:Perforce.P4.ChangeCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.GetChangelist(System.Int32,Perforce.P4.Options)">
<summary>
Get the record for an existing change from the repository.
</summary>
<param name="change">Changelist name</param>
<param name="options">'-f' or '-s' are valid flags to use when fetching an existing change</param>
<returns>The Changelist object if new change was found, null if creation failed</returns>
<remarks>
<br/>
<br/><b>p4 help change</b>
<br/>
<br/> change -- Create or edit a changelist description
<br/> changelist -- synonym for 'change'
<br/>
<br/> p4 change [-s] [-f | -u] [[-O] changelist#]
<br/> p4 change -d [-f -s -O] changelist#
<br/> p4 change -o [-s] [-f] [[-O] changelist#]
<br/> p4 change -i [-s] [-f | -u]
<br/> p4 change -t restricted | public [-U user] [-f | -u | -O] changelist#
<br/> p4 change -U user [-t restricted | public] [-f] changelist#
<br/>
<br/> 'p4 change' creates and edits changelists and their descriptions.
<br/> With no argument, 'p4 change' creates a new changelist. If a
<br/> changelist number is specified, 'p4 change' edits an existing
<br/> pending changelist. In both cases, the changelist specification
<br/> is placed into a form and the user's editor is invoked.
<br/>
<br/> The -d flag deletes a pending changelist, if it has no opened files
<br/> and no pending fixes associated with it. Use 'p4 opened -a' to
<br/> report on opened files and 'p4 reopen' to move them to another
<br/> changelist. Use 'p4 fixes -c changelist#' to report on pending
<br/> fixes and 'p4 fix -d -c changelist# jobs...' to delete pending
<br/> fixes. The changelist can be deleted only by the user and client
<br/> who created it, or by a user with 'admin' privilege using the -f
<br/> flag.
<br/>
<br/> The -o flag writes the changelist specification to the standard
<br/> output. The user's editor is not invoked.
<br/>
<br/> The -i flag reads a changelist specification from the standard
<br/> input. The user's editor is not invoked.
<br/>
<br/> The -f flag forces the update or deletion of other users' pending
<br/> changelists. -f can also force the deletion of submitted changelists
<br/> after they have been emptied of files using 'p4 obliterate'. By
<br/> default, submitted changelists cannot be changed. The -f flag can
<br/> also force display of the 'Description' field in a restricted
<br/> changelist. Finally the -f flag can force changing the 'User' of
<br/> an empty pending change via -U. The -f flag requires 'admin'
<br/> access granted by 'p4 protect'. The -f and -u flags are mutually
<br/> exclusive.
<br/>
<br/> The -u flag can force the update of a submitted change by the owner
<br/> of the change. Only the Jobs, Type, and Description fields can be
<br/> changed using the -u flag. The -f and -u flags cannot be used in
<br/> the same change command.
<br/>
<br/> The -s flag extends the list of jobs to include the fix status
<br/> for each job. On new changelists, the fix status begins as the
<br/> special status 'ignore', which, if left unchanged simply excludes
<br/> the job from those being fixed. Otherwise, the fix status, like
<br/> that applied with 'p4 fix -s', becomes the job's status when
<br/> the changelist is committed. Note that this option exists
<br/> to support integration with external defect trackers.
<br/>
<br/> The -O flag specifies that the changelist number is the original
<br/> number of a changelist which was renamed on submit.
<br/>
<br/> The -U flag changes the 'User' of an empty pending change to the
<br/> specified user. The user field can only be changed using this flag
<br/> by the user who created the change, or by a user with 'admin'
<br/> privilege using the -f flag. This option is useful for running
<br/> in a trigger or script.
<br/>
<br/> The -t flag changes the 'Type' of the change to 'restricted'
<br/> or 'public' without displaying the change form. This option is
<br/> useful for running in a trigger or script.
<br/>
<br/> The 'Type' field can be used to hide the change or its description
<br/> from users. Valid values for this field are 'public' (default), and
<br/> 'restricted'. A shelved or committed change that is 'restricted' is
<br/> accessible only to users who own the change or have 'list' permission
<br/> to at least one file in the change. A pending (not shelved)
<br/> restricted change is only accessible to its owner. Public changes
<br/> are accessible to all users. This setting affects the output of the
<br/> 'p4 change', 'p4 changes', and 'p4 describe' commands. Note that
<br/> the '-S' flag is required with 'p4 describe' for the command to
<br/> enforce shelved rather than pending restricted changelist rules.
<br/>
<br/> If a user is not permitted to have access to a restricted change,
<br/> The 'Description' text is replaced with a 'no permission' message
<br/> (see 'Type' field). Users with admin permission can override the
<br/> restriction using the -f flag.
<br/>
<br/>
</remarks>
<example>
To get changelist 25:
<code>
Changelist c = Repository.GetChangelist(25, null);
</code>
</example>
<seealso cref="T:Perforce.P4.ChangeCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.GetChangelist(System.Int32)">
<summary>
Get the record for an existing change from the repository.
</summary>
<param name="change">Changelist name</param>
<param name="options">'-f' or '-s' are valid flags to use when fetching an existing change</param>
<returns>The Changelist object if new change was found, null if creation failed</returns>
<remarks>
<br/>
<br/><b>p4 help change</b>
<br/>
<br/> change -- Create or edit a changelist description
<br/> changelist -- synonym for 'change'
<br/>
<br/> p4 change [-s] [-f | -u] [[-O] changelist#]
<br/> p4 change -d [-f -s -O] changelist#
<br/> p4 change -o [-s] [-f] [[-O] changelist#]
<br/> p4 change -i [-s] [-f | -u]
<br/> p4 change -t restricted | public [-U user] [-f | -u | -O] changelist#
<br/> p4 change -U user [-t restricted | public] [-f] changelist#
<br/>
<br/> 'p4 change' creates and edits changelists and their descriptions.
<br/> With no argument, 'p4 change' creates a new changelist. If a
<br/> changelist number is specified, 'p4 change' edits an existing
<br/> pending changelist. In both cases, the changelist specification
<br/> is placed into a form and the user's editor is invoked.
<br/>
<br/> The -d flag deletes a pending changelist, if it has no opened files
<br/> and no pending fixes associated with it. Use 'p4 opened -a' to
<br/> report on opened files and 'p4 reopen' to move them to another
<br/> changelist. Use 'p4 fixes -c changelist#' to report on pending
<br/> fixes and 'p4 fix -d -c changelist# jobs...' to delete pending
<br/> fixes. The changelist can be deleted only by the user and client
<br/> who created it, or by a user with 'admin' privilege using the -f
<br/> flag.
<br/>
<br/> The -o flag writes the changelist specification to the standard
<br/> output. The user's editor is not invoked.
<br/>
<br/> The -i flag reads a changelist specification from the standard
<br/> input. The user's editor is not invoked.
<br/>
<br/> The -f flag forces the update or deletion of other users' pending
<br/> changelists. -f can also force the deletion of submitted changelists
<br/> after they have been emptied of files using 'p4 obliterate'. By
<br/> default, submitted changelists cannot be changed. The -f flag can
<br/> also force display of the 'Description' field in a restricted
<br/> changelist. Finally the -f flag can force changing the 'User' of
<br/> an empty pending change via -U. The -f flag requires 'admin'
<br/> access granted by 'p4 protect'. The -f and -u flags are mutually
<br/> exclusive.
<br/>
<br/> The -u flag can force the update of a submitted change by the owner
<br/> of the change. Only the Jobs, Type, and Description fields can be
<br/> changed using the -u flag. The -f and -u flags cannot be used in
<br/> the same change command.
<br/>
<br/> The -s flag extends the list of jobs to include the fix status
<br/> for each job. On new changelists, the fix status begins as the
<br/> special status 'ignore', which, if left unchanged simply excludes
<br/> the job from those being fixed. Otherwise, the fix status, like
<br/> that applied with 'p4 fix -s', becomes the job's status when
<br/> the changelist is committed. Note that this option exists
<br/> to support integration with external defect trackers.
<br/>
<br/> The -O flag specifies that the changelist number is the original
<br/> number of a changelist which was renamed on submit.
<br/>
<br/> The -U flag changes the 'User' of an empty pending change to the
<br/> specified user. The user field can only be changed using this flag
<br/> by the user who created the change, or by a user with 'admin'
<br/> privilege using the -f flag. This option is useful for running
<br/> in a trigger or script.
<br/>
<br/> The -t flag changes the 'Type' of the change to 'restricted'
<br/> or 'public' without displaying the change form. This option is
<br/> useful for running in a trigger or script.
<br/>
<br/> The 'Type' field can be used to hide the change or its description
<br/> from users. Valid values for this field are 'public' (default), and
<br/> 'restricted'. A shelved or committed change that is 'restricted' is
<br/> accessible only to users who own the change or have 'list' permission
<br/> to at least one file in the change. A pending (not shelved)
<br/> restricted change is only accessible to its owner. Public changes
<br/> are accessible to all users. This setting affects the output of the
<br/> 'p4 change', 'p4 changes', and 'p4 describe' commands. Note that
<br/> the '-S' flag is required with 'p4 describe' for the command to
<br/> enforce shelved rather than pending restricted changelist rules.
<br/>
<br/> If a user is not permitted to have access to a restricted change,
<br/> The 'Description' text is replaced with a 'no permission' message
<br/> (see 'Type' field). Users with admin permission can override the
<br/> restriction using the -f flag.
<br/>
<br/>
</remarks>
<example>
To get changelist 25:
<code>
Changelist c = Repository.GetChangelist(25);
</code>
</example>
</member>
<member name="M:Perforce.P4.Repository.GetChangelists(Perforce.P4.Options,Perforce.P4.FileSpec[])">
<summary>
Get a list of changes from the repository
</summary>
<param name="options">options for the changes command<see cref="!:ChangelistsOptions"/></param>
<param name="files">array of FileSpecs for the changes command</param>
<returns>A list containing the matching changes</returns>
<remarks>
<br/><b>p4 help changes</b>
<br/>
<br/> changes -- Display list of pending and submitted changelists
<br/> changelists -- synonym for 'changes'
<br/>
<br/> p4 changes [options] [file[revRange] ...]
<br/>
<br/> options: -i -t -l -L -f -c client -m max -s status -u user
<br/>
<br/> Returns a list of all pending and submitted changelists currently
<br/> stored in the server.
<br/>
<br/> If files are specified, 'p4 changes' lists only changelists that
<br/> affect those files. If the file specification includes a revision
<br/> range, 'p4 changes' lists only submitted changelists that affect
<br/> the specified revisions. See 'p4 help revisions' for details.
<br/>
<br/> If files are not specified, 'p4 changes' limits its report
<br/> according to each change's type ('public' or 'restricted').
<br/> If a submitted or shelved change is restricted, the change is
<br/> not reported unless the user owns the change or has list
<br/> permission for at least one file in the change. Only the owner
<br/> of a restricted and pending (not shelved) change is permitted
<br/> to see it.
<br/>
<br/> The -i flag also includes any changelists integrated into the
<br/> specified files.
<br/>
<br/> The -t flag displays the time as well as the date.
<br/>
<br/> The -l flag displays the full text of the changelist
<br/> descriptions.
<br/>
<br/> The -L flag displays the changelist descriptions, truncated to 250
<br/> characters if longer.
<br/>
<br/> The -f flag enables admin users to view restricted changes.
<br/>
<br/> The -c client flag displays only submitted by the specified client.
<br/>
<br/> The -m max flag limits changes to the 'max' most recent.
<br/>
<br/> The -s status flag limits the output to changelists with the specified
<br/> status. Specify '-s pending', '-s shelved', or '-s submitted'.
<br/>
<br/> The -u user flag displays only changes owned by the specified user.
<br/>
<br/>
</remarks>
<example>
To get all changelists owned by user bsmith:
<code>
ChangesCmdOptions opts =new ChangesCmdOptions(ChangesCmdFlags.None,
null, 0, ChangeListStatus.None, "bsmith");
IList<Changelist> changes =
Repository.GetChangelists(opts, null);
</code>
To get all shelved changelists in file path //depot/main/...:
<code>
ChangesCmdOptions opts =new ChangesCmdOptions(ChangesCmdFlags.None,
null, 0, ChangeListStatus.Shelved, null);
FileSpec file =
new FileSpec(new DepotPath("//depot/main/..."), null, null, null);
IList<Changelist> changes =
Repository.GetChangelists(opts, file);
</code>
To the 20 latest submitted changelists from client "build_workspace"
with their full description:
<code>
ChangesCmdOptions opts =new ChangesCmdOptions(ChangesCmdFlags.FullDescription,
"build_workspace", 20, ChangeListStatus.Submitted, null);
IList<Changelist> changes =
Repository.GetChangelists(opts, null);
</code>
To get all pending changelists as an admin user in file path
//depot/finance/... including restricted changelists:
<code>
ChangesCmdOptions opts =new ChangesCmdOptions(ChangesCmdFlags.ViewRestricted,
null, 0, ChangeListStatus.Pending, null);
FileSpec file =
new FileSpec(new DepotPath("//depot/finance/..."), null, null, null);
IList<Changelist> changes =
Repository.GetChangelists(opts, file);
</code>
</example>
<seealso cref="T:Perforce.P4.ChangesCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.DeleteChangelist(Perforce.P4.Changelist,Perforce.P4.Options)">
<summary>
Delete a change from the repository
</summary>
<param name="change">The change to be deleted</param>
<param name="options">The '-f' and '-s' flags are valid when deleting an existing change</param>
<summary>
Get the record for an existing change from the repository.
</summary>
<param name="change">Changelist name</param>
<param name="options">'-f' is a valid flag to use when deleting an existing change</param>
<returns>The Changelist object if new change was found, null if creation failed</returns>
<remarks>
<br/>
<br/><b>p4 help change</b>
<br/>
<br/> change -- Create or edit a changelist description
<br/> changelist -- synonym for 'change'
<br/>
<br/> p4 change [-s] [-f | -u] [[-O] changelist#]
<br/> p4 change -d [-f -s -O] changelist#
<br/> p4 change -o [-s] [-f] [[-O] changelist#]
<br/> p4 change -i [-s] [-f | -u]
<br/> p4 change -t restricted | public [-U user] [-f | -u | -O] changelist#
<br/> p4 change -U user [-t restricted | public] [-f] changelist#
<br/>
<br/> 'p4 change' creates and edits changelists and their descriptions.
<br/> With no argument, 'p4 change' creates a new changelist. If a
<br/> changelist number is specified, 'p4 change' edits an existing
<br/> pending changelist. In both cases, the changelist specification
<br/> is placed into a form and the user's editor is invoked.
<br/>
<br/> The -d flag deletes a pending changelist, if it has no opened files
<br/> and no pending fixes associated with it. Use 'p4 opened -a' to
<br/> report on opened files and 'p4 reopen' to move them to another
<br/> changelist. Use 'p4 fixes -c changelist#' to report on pending
<br/> fixes and 'p4 fix -d -c changelist# jobs...' to delete pending
<br/> fixes. The changelist can be deleted only by the user and client
<br/> who created it, or by a user with 'admin' privilege using the -f
<br/> flag.
<br/>
<br/> The -o flag writes the changelist specification to the standard
<br/> output. The user's editor is not invoked.
<br/>
<br/> The -i flag reads a changelist specification from the standard
<br/> input. The user's editor is not invoked.
<br/>
<br/> The -f flag forces the update or deletion of other users' pending
<br/> changelists. -f can also force the deletion of submitted changelists
<br/> after they have been emptied of files using 'p4 obliterate'. By
<br/> default, submitted changelists cannot be changed. The -f flag can
<br/> also force display of the 'Description' field in a restricted
<br/> changelist. Finally the -f flag can force changing the 'User' of
<br/> an empty pending change via -U. The -f flag requires 'admin'
<br/> access granted by 'p4 protect'. The -f and -u flags are mutually
<br/> exclusive.
<br/>
<br/> The -u flag can force the update of a submitted change by the owner
<br/> of the change. Only the Jobs, Type, and Description fields can be
<br/> changed using the -u flag. The -f and -u flags cannot be used in
<br/> the same change command.
<br/>
<br/> The -s flag extends the list of jobs to include the fix status
<br/> for each job. On new changelists, the fix status begins as the
<br/> special status 'ignore', which, if left unchanged simply excludes
<br/> the job from those being fixed. Otherwise, the fix status, like
<br/> that applied with 'p4 fix -s', becomes the job's status when
<br/> the changelist is committed. Note that this option exists
<br/> to support integration with external defect trackers.
<br/>
<br/> The -O flag specifies that the changelist number is the original
<br/> number of a changelist which was renamed on submit.
<br/>
<br/> The -U flag changes the 'User' of an empty pending change to the
<br/> specified user. The user field can only be changed using this flag
<br/> by the user who created the change, or by a user with 'admin'
<br/> privilege using the -f flag. This option is useful for running
<br/> in a trigger or script.
<br/>
<br/> The -t flag changes the 'Type' of the change to 'restricted'
<br/> or 'public' without displaying the change form. This option is
<br/> useful for running in a trigger or script.
<br/>
<br/> The 'Type' field can be used to hide the change or its description
<br/> from users. Valid values for this field are 'public' (default), and
<br/> 'restricted'. A shelved or committed change that is 'restricted' is
<br/> accessible only to users who own the change or have 'list' permission
<br/> to at least one file in the change. A pending (not shelved)
<br/> restricted change is only accessible to its owner. Public changes
<br/> are accessible to all users. This setting affects the output of the
<br/> 'p4 change', 'p4 changes', and 'p4 describe' commands. Note that
<br/> the '-S' flag is required with 'p4 describe' for the command to
<br/> enforce shelved rather than pending restricted changelist rules.
<br/>
<br/> If a user is not permitted to have access to a restricted change,
<br/> The 'Description' text is replaced with a 'no permission' message
<br/> (see 'Type' field). Users with admin permission can override the
<br/> restriction using the -f flag.
<br/>
<br/>
</remarks>
<example>
To delete pending changelist 34:
<code>
Repository.DeleteChangelist(34,null);
</code>
To delete pending changelist 34 as an admin user
who is not owner of the change:
<code>
ChangeCmdOptions opts = new ChangeCmdOptions(ChangeCmdFlags.Force);
Repository.DeleteChangelist(34, opts);
</code>
</example>
<seealso cref="T:Perforce.P4.ChangeCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.CreateClient(Perforce.P4.Client,Perforce.P4.Options)">
<summary>
Create a new client in the repository.
</summary>
<param name="client">Client specification for the new user</param>
<param name="options">The '-i' flags is required when creating a new user</param>
<returns>The Client object if new user was created, null if creation failed</returns>
<remarks> The '-i' flag is added if not specified by the caller
<br/>
<br/><b>p4 help client</b>
<br/>
<br/> client -- Create or edit a client workspace specification and its view
<br/> workspace -- Synonym for 'client'
<br/>
<br/> p4 client [-f] [-t template] [name]
<br/> p4 client -d [-f [-Fs]] name
<br/> p4 client -o [-t template] [name]
<br/> p4 client -S stream [[-c change] -o] [name]
<br/> p4 client -s [-f] -S stream [name]
<br/> p4 client -s [-f] -t template [name]
<br/> p4 client -i [-f]
<br/>
<br/> Creates a new client specification ('spec') or edits an existing
<br/> spec. A client spec is a named mapping of depot files to workspace
<br/> files.
<br/>
<br/> The 'p4 client' command puts the client spec into a temporary file
<br/> and invokes the editor configured by the environment variable
<br/> $P4EDITOR. For new workspaces, the client name defaults to the
<br/> $P4CLIENT environment variable, if set, or to the current host name.
<br/> Saving the file creates or modifies the client spec.
<br/>
<br/> The client spec contains the following fields:
<br/>
<br/> Client: The client name.
<br/>
<br/> Host: If set, restricts access to the named host.
<br/> If unset, access is allowed from any host.
<br/>
<br/> Owner: The user who created this client.
<br/>
<br/> Update: The date that this spec was last modified.
<br/>
<br/> Access: The date that this client was last used in any way.
<br/>
<br/> Description: A short description of the workspace.
<br/>
<br/> Root: The root directory of the workspace (specified in local
<br/> file system syntax), under which all versioned files
<br/> will be placed. If you change this setting, you must
<br/> physically relocate any files that currently reside
<br/> there. On Windows client machines, you can specify the
<br/> root as "null" to enable you to map files to multiple
<br/> drives.
<br/>
<br/> AltRoots: Up to two optional alternate client workspace roots.
<br/> The first of the main and alternate roots to match the
<br/> client program's current working directory is used. If
<br/> none match, the main root is used. 'p4 info' displays
<br/> the root that is being used.
<br/>
<br/> Options: Flags to configure the client behavior. Defaults
<br/> are marked with *.
<br/>
<br/> allwrite Leaves all files writable on the client;
<br/> noallwrite * by default, only files opened by 'p4 edit'
<br/> are writable. If set, files might be clobbered
<br/> as a result of ignoring the clobber option
<br/> (see below).
<br/>
<br/> clobber Permits 'p4 sync' to overwrite writable
<br/> noclobber * files on the client. noclobber is ignored if
<br/> allwrite is set.
<br/>
<br/> compress Compresses data sent between the client
<br/> nocompress * and server to speed up slow connections.
<br/>
<br/> locked Allows only the client owner to use or change
<br/> unlocked * the client spec. Prevents the client spec from
<br/> being deleted or unloaded.
<br/>
<br/> modtime Causes 'p4 sync' and 'p4 submit' to preserve
<br/> nomodtime * file modification time, as with files with the
<br/> +m type modifier. (See 'p4 help filetypes'.)
<br/> With nomodtime, file timestamps are updated by
<br/> sync and submit operations.
<br/>
<br/> rmdir Makes 'p4 sync' attempt to delete a workspace
<br/> normdir * directory when all files in it are removed.
<br/>
<br/> SubmitOptions: Flags to change submit behavior.
<br/>
<br/> submitunchanged All open files are submitted (default).
<br/>
<br/> revertunchanged Files that have content, type, or resolved
<br/> changes are submitted. Unchanged files are
<br/> reverted.
<br/>
<br/> leaveunchanged Files that have content, type, or resolved
<br/> changes are submitted. Unchanged files are
<br/> moved to the default changelist.
<br/>
<br/> +reopen Can be appended to the submit option flag
<br/> to cause submitted files to be reopened in
<br/> the default changelist.
<br/> Example: submitunchanged+reopen
<br/>
<br/> LineEnd: Set line-ending character(s) for client text files.
<br/>
<br/> local mode that is native to the client (default).
<br/> unix linefeed: UNIX style.
<br/> mac carriage return: Macintosh style.
<br/> win carriage return-linefeed: Windows style.
<br/> share hybrid: writes UNIX style but reads UNIX,
<br/> Mac or Windows style.
<br/>
<br/> View: Maps files in the depot to files in your client
<br/> workspace. Defines the files that you want in your
<br/> client workspace and specifies where you want them
<br/> to reside. The default view maps all depot files
<br/> onto the client. See 'p4 help views' for view syntax.
<br/> A new view takes effect on the next 'p4 sync'.
<br/>
<br/> ChangeView: Restricts depot paths to a particular point in time.
<br/> Example: //depot/path/...@1000
<br/> Revisions submitted to the path after the specified
<br/> changelist will not be visible. Files matching a
<br/> ChangeView path may not be submitted.
<br/>
<br/> Stream: The stream to which this client's view will be dedicated.
<br/> (Files in stream paths can be submitted only by dedicated
<br/> stream clients.) When this optional field is set, the
<br/> View field will be automatically replaced by a stream
<br/> view as the client spec is saved.
<br/>
<br/> StreamAtChange:
<br/> Stream meta-data (for view creation) is versioned.
<br/> When StreamAtChange is set, the stream hierarchy is
<br/> constructed back-in-time to reproduce the view that was
<br/> available to clients in the past. With this field set
<br/> changes cannot be be submitted from the client.
<br/> StreamAtChange is optional; Stream must be set as well.
<br/>
<br/> ServerID: If set, restricts usage to the named server.
<br/> If unset, usage is allowed on the master server and on
<br/> any replicas of the master other than Edge Servers.
<br/>
<br/> Note: changing the client root does not actually move the client
<br/> files; you must relocate them manually. Similarly, changing
<br/> the 'LineEnd' option does not actually update the client files;
<br/> you can refresh them with 'p4 sync -f'.
<br/>
<br/> The -d flag deletes the specified spec, as long as the client
<br/> workspace has no opened files or pending changes. (See 'p4 help
<br/> opened'.) The -f flag forces the delete. The -Fs option used with -f
<br/> forces client deletion even when the user has shelved changes. In
<br/> this case, the shelved changes are left intact.
<br/>
<br/> The -o flag writes the named client spec to the standard output.
<br/> The user's editor is not invoked.
<br/>
<br/> The -i flag reads a client spec from the standard input. The
<br/> user's editor is not invoked.
<br/>
<br/> The -t template flag, where 'template' is the name of another client
<br/> spec, causes the View and Options fields to be replaced by those of
<br/> the template.
<br/>
<br/> The -f flag can force the updating of locked clients; normally
<br/> locked clients can only be modified by their owner. -f also allows
<br/> the last modified date to be set. The -f flag requires 'admin'
<br/> access granted by 'p4 protect'.
<br/>
<br/> The -s flag is used to switch an existing client spec's view without
<br/> invoking the editor. It can be used with -S to switch to a stream
<br/> view, or with -t to switch to a view defined in another client spec.
<br/> Switching views is not allowed in a client that has opened files.
<br/> The -f flag can be used with -s to force switching with opened files.
<br/> View switching has no effect on files in a client workspace until
<br/> 'p4 sync' is run.
<br/>
<br/> Without -s, the '-S stream' flag can be used to create a new client
<br/> spec dedicated to a stream. If the client spec already exists, and
<br/> -S is used without -s, an error occurs when the client is bound to
<br/> a different, or no stream. Using -S sets the new client's
<br/> Stream field. The special syntax '-S //a/stream@changelist' can
<br/> be used to set both Stream and StreamAtChange at the same time.
<br/>
<br/> The '-S stream' flag can be used with '-o -c change' to inspect an
<br/> old stream client view. It yields the client spec that would have
<br/> been created for the stream at the moment the change was recorded.
<br/>
<br/> A server of type 'build-server' (see 'p4 help server') is a replica
<br/> which supports build farm integration, and the 'p4 client' command
<br/> may be used to create or edit client workspaces on a build-server.
<br/> Such workspaces may issue the 'p4 sync' command, in addition to any
<br/> read-only command supported by the replica. For more information, run
<br/> 'p4 help buildserver'.
<br/>
<br/> When creating or editing a client workspace for a build-server,
<br/> the client specified by the optional 'name' argument, as well as the
<br/> client specified by the $P4CLIENT environment variable or via the
<br/> global '-c client' argument must not exist, or must be restricted
<br/> to this server; this command may not be used to create or edit a
<br/> workspace that is not restricted to this build-server.
<br/>
<br/>
<br/>
</remarks>
<example>
To create a client named main_ws:
<code>
Client c = Repository.GetClient("main_ws");
c.OwnerName= "bsmith";
c.Description = "client for main dev";
Repository.CreateClient(c, null);
</code>
To create a client named main_ws using existing admin_main_ws
as a template:
<code>
ClientCmdOptions opts =
new ClientCmdOptions(ClientCmdFlags.None, "admin_main_ws", null, 0);
Client c = Repository.GetClient("main_ws",opts);
Repository.CreateClient(c, null);
</code>
To create a streams client named main_ws for the mainline stream
//MobileApp/Main:
<code>
ClientCmdOptions opts =
new ClientCmdOptions(ClientCmdFlags.None, null, "//MobileApp/Main", 0);
Client c = Repository.GetClient("main_ws",opts);
Repository.CreateClient(c, null);
</code>
</example>
<seealso cref="T:Perforce.P4.ClientCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.CreateClient(Perforce.P4.Client)">
<summary>
Create a new client in the repository.
</summary>
<param name="client">Client specification for the new user</param>
<param name="options">The '-i' flags is required when creating a new user</param>
<returns>The Client object if new user was created, null if creation failed</returns>
<remarks> The '-i' flag is added if not specified by the caller
<br/>
<br/><b>p4 help client</b>
<br/>
<br/> client -- Create or edit a client workspace specification and its view
<br/> workspace -- Synonym for 'client'
<br/>
<br/> p4 client [-f] [-t template] [name]
<br/> p4 client -d [-f [-Fs]] name
<br/> p4 client -o [-t template] [name]
<br/> p4 client -S stream [[-c change] -o] [name]
<br/> p4 client -s [-f] -S stream [name]
<br/> p4 client -s [-f] -t template [name]
<br/> p4 client -i [-f]
<br/>
<br/> Creates a new client specification ('spec') or edits an existing
<br/> spec. A client spec is a named mapping of depot files to workspace
<br/> files.
<br/>
<br/> The 'p4 client' command puts the client spec into a temporary file
<br/> and invokes the editor configured by the environment variable
<br/> $P4EDITOR. For new workspaces, the client name defaults to the
<br/> $P4CLIENT environment variable, if set, or to the current host name.
<br/> Saving the file creates or modifies the client spec.
<br/>
<br/> The client spec contains the following fields:
<br/>
<br/> Client: The client name.
<br/>
<br/> Host: If set, restricts access to the named host.
<br/> If unset, access is allowed from any host.
<br/>
<br/> Owner: The user who created this client.
<br/>
<br/> Update: The date that this spec was last modified.
<br/>
<br/> Access: The date that this client was last used in any way.
<br/>
<br/> Description: A short description of the workspace.
<br/>
<br/> Root: The root directory of the workspace (specified in local
<br/> file system syntax), under which all versioned files
<br/> will be placed. If you change this setting, you must
<br/> physically relocate any files that currently reside
<br/> there. On Windows client machines, you can specify the
<br/> root as "null" to enable you to map files to multiple
<br/> drives.
<br/>
<br/> AltRoots: Up to two optional alternate client workspace roots.
<br/> The first of the main and alternate roots to match the
<br/> client program's current working directory is used. If
<br/> none match, the main root is used. 'p4 info' displays
<br/> the root that is being used.
<br/>
<br/> Options: Flags to configure the client behavior. Defaults
<br/> are marked with *.
<br/>
<br/> allwrite Leaves all files writable on the client;
<br/> noallwrite * by default, only files opened by 'p4 edit'
<br/> are writable. If set, files might be clobbered
<br/> as a result of ignoring the clobber option
<br/> (see below).
<br/>
<br/> clobber Permits 'p4 sync' to overwrite writable
<br/> noclobber * files on the client. noclobber is ignored if
<br/> allwrite is set.
<br/>
<br/> compress Compresses data sent between the client
<br/> nocompress * and server to speed up slow connections.
<br/>
<br/> locked Allows only the client owner to use or change
<br/> unlocked * the client spec. Prevents the client spec from
<br/> being deleted or unloaded.
<br/>
<br/> modtime Causes 'p4 sync' and 'p4 submit' to preserve
<br/> nomodtime * file modification time, as with files with the
<br/> +m type modifier. (See 'p4 help filetypes'.)
<br/> With nomodtime, file timestamps are updated by
<br/> sync and submit operations.
<br/>
<br/> rmdir Makes 'p4 sync' attempt to delete a workspace
<br/> normdir * directory when all files in it are removed.
<br/>
<br/> SubmitOptions: Flags to change submit behavior.
<br/>
<br/> submitunchanged All open files are submitted (default).
<br/>
<br/> revertunchanged Files that have content, type, or resolved
<br/> changes are submitted. Unchanged files are
<br/> reverted.
<br/>
<br/> leaveunchanged Files that have content, type, or resolved
<br/> changes are submitted. Unchanged files are
<br/> moved to the default changelist.
<br/>
<br/> +reopen Can be appended to the submit option flag
<br/> to cause submitted files to be reopened in
<br/> the default changelist.
<br/> Example: submitunchanged+reopen
<br/>
<br/> LineEnd: Set line-ending character(s) for client text files.
<br/>
<br/> local mode that is native to the client (default).
<br/> unix linefeed: UNIX style.
<br/> mac carriage return: Macintosh style.
<br/> win carriage return-linefeed: Windows style.
<br/> share hybrid: writes UNIX style but reads UNIX,
<br/> Mac or Windows style.
<br/>
<br/> View: Maps files in the depot to files in your client
<br/> workspace. Defines the files that you want in your
<br/> client workspace and specifies where you want them
<br/> to reside. The default view maps all depot files
<br/> onto the client. See 'p4 help views' for view syntax.
<br/> A new view takes effect on the next 'p4 sync'.
<br/>
<br/> ChangeView: Restricts depot paths to a particular point in time.
<br/> Example: //depot/path/...@1000
<br/> Revisions submitted to the path after the specified
<br/> changelist will not be visible. Files matching a
<br/> ChangeView path may not be submitted.
<br/>
<br/> Stream: The stream to which this client's view will be dedicated.
<br/> (Files in stream paths can be submitted only by dedicated
<br/> stream clients.) When this optional field is set, the
<br/> View field will be automatically replaced by a stream
<br/> view as the client spec is saved.
<br/>
<br/> StreamAtChange:
<br/> Stream meta-data (for view creation) is versioned.
<br/> When StreamAtChange is set, the stream hierarchy is
<br/> constructed back-in-time to reproduce the view that was
<br/> available to clients in the past. With this field set
<br/> changes cannot be be submitted from the client.
<br/> StreamAtChange is optional; Stream must be set as well.
<br/>
<br/> ServerID: If set, restricts usage to the named server.
<br/> If unset, usage is allowed on the master server and on
<br/> any replicas of the master other than Edge Servers.
<br/>
<br/> Note: changing the client root does not actually move the client
<br/> files; you must relocate them manually. Similarly, changing
<br/> the 'LineEnd' option does not actually update the client files;
<br/> you can refresh them with 'p4 sync -f'.
<br/>
<br/> The -d flag deletes the specified spec, as long as the client
<br/> workspace has no opened files or pending changes. (See 'p4 help
<br/> opened'.) The -f flag forces the delete. The -Fs option used with -f
<br/> forces client deletion even when the user has shelved changes. In
<br/> this case, the shelved changes are left intact.
<br/>
<br/> The -o flag writes the named client spec to the standard output.
<br/> The user's editor is not invoked.
<br/>
<br/> The -i flag reads a client spec from the standard input. The
<br/> user's editor is not invoked.
<br/>
<br/> The -t template flag, where 'template' is the name of another client
<br/> spec, causes the View and Options fields to be replaced by those of
<br/> the template.
<br/>
<br/> The -f flag can force the updating of locked clients; normally
<br/> locked clients can only be modified by their owner. -f also allows
<br/> the last modified date to be set. The -f flag requires 'admin'
<br/> access granted by 'p4 protect'.
<br/>
<br/> The -s flag is used to switch an existing client spec's view without
<br/> invoking the editor. It can be used with -S to switch to a stream
<br/> view, or with -t to switch to a view defined in another client spec.
<br/> Switching views is not allowed in a client that has opened files.
<br/> The -f flag can be used with -s to force switching with opened files.
<br/> View switching has no effect on files in a client workspace until
<br/> 'p4 sync' is run.
<br/>
<br/> Without -s, the '-S stream' flag can be used to create a new client
<br/> spec dedicated to a stream. If the client spec already exists, and
<br/> -S is used without -s, an error occurs when the client is bound to
<br/> a different, or no stream. Using -S sets the new client's
<br/> Stream field. The special syntax '-S //a/stream@changelist' can
<br/> be used to set both Stream and StreamAtChange at the same time.
<br/>
<br/> The '-S stream' flag can be used with '-o -c change' to inspect an
<br/> old stream client view. It yields the client spec that would have
<br/> been created for the stream at the moment the change was recorded.
<br/>
<br/> A server of type 'build-server' (see 'p4 help server') is a replica
<br/> which supports build farm integration, and the 'p4 client' command
<br/> may be used to create or edit client workspaces on a build-server.
<br/> Such workspaces may issue the 'p4 sync' command, in addition to any
<br/> read-only command supported by the replica. For more information, run
<br/> 'p4 help buildserver'.
<br/>
<br/> When creating or editing a client workspace for a build-server,
<br/> the client specified by the optional 'name' argument, as well as the
<br/> client specified by the $P4CLIENT environment variable or via the
<br/> global '-c client' argument must not exist, or must be restricted
<br/> to this server; this command may not be used to create or edit a
<br/> workspace that is not restricted to this build-server.
<br/>
<br/>
<br/>
</remarks>
<example>
To create a client named main_ws:
<code>
Client c = Repository.GetClient("main_ws");
c.OwnerName= "bsmith";
c.Description = "client for main dev";
Repository.CreateClient(c);
</code>
To create a client named main_ws using existing admin_main_ws
as a template:
<code>
ClientCmdOptions opts =
new ClientCmdOptions(ClientCmdFlags.None, "admin_main_ws", null, 0);
Client c = Repository.GetClient("main_ws",opts);
Repository.CreateClient(c);
</code>
To create a streams client named main_ws for the mainline stream
//MobileApp/Main:
<code>
ClientCmdOptions opts =
new ClientCmdOptions(ClientCmdFlags.None, null, "//MobileApp/Main", 0);
Client c = Repository.GetClient("main_ws",opts);
Repository.CreateClient(c);
</code>
</example>
</member>
<member name="M:Perforce.P4.Repository.UpdateClient(Perforce.P4.Client)">
<summary>
Update the record for a client in the repository
</summary>
<param name="client">Client specification for the client being updated</param>
<returns>The Client object if new client was saved, null if creation failed</returns>
<summary>
Create a new client in the repository.
</summary>
<param name="client">Client specification for the new user</param>
<param name="options">The '-i' flags is required when creating a new user</param>
<returns>The Client object if new user was created, null if creation failed</returns>
<remarks> The '-i' flag is added if not specified by the caller
<br/>
<br/><b>p4 help client</b>
<br/>
<br/> client -- Create or edit a client workspace specification and its view
<br/> workspace -- Synonym for 'client'
<br/>
<br/> p4 client [-f] [-t template] [name]
<br/> p4 client -d [-f [-Fs]] name
<br/> p4 client -o [-t template] [name]
<br/> p4 client -S stream [[-c change] -o] [name]
<br/> p4 client -s [-f] -S stream [name]
<br/> p4 client -s [-f] -t template [name]
<br/> p4 client -i [-f]
<br/>
<br/> Creates a new client specification ('spec') or edits an existing
<br/> spec. A client spec is a named mapping of depot files to workspace
<br/> files.
<br/>
<br/> The 'p4 client' command puts the client spec into a temporary file
<br/> and invokes the editor configured by the environment variable
<br/> $P4EDITOR. For new workspaces, the client name defaults to the
<br/> $P4CLIENT environment variable, if set, or to the current host name.
<br/> Saving the file creates or modifies the client spec.
<br/>
<br/> The client spec contains the following fields:
<br/>
<br/> Client: The client name.
<br/>
<br/> Host: If set, restricts access to the named host.
<br/> If unset, access is allowed from any host.
<br/>
<br/> Owner: The user who created this client.
<br/>
<br/> Update: The date that this spec was last modified.
<br/>
<br/> Access: The date that this client was last used in any way.
<br/>
<br/> Description: A short description of the workspace.
<br/>
<br/> Root: The root directory of the workspace (specified in local
<br/> file system syntax), under which all versioned files
<br/> will be placed. If you change this setting, you must
<br/> physically relocate any files that currently reside
<br/> there. On Windows client machines, you can specify the
<br/> root as "null" to enable you to map files to multiple
<br/> drives.
<br/>
<br/> AltRoots: Up to two optional alternate client workspace roots.
<br/> The first of the main and alternate roots to match the
<br/> client program's current working directory is used. If
<br/> none match, the main root is used. 'p4 info' displays
<br/> the root that is being used.
<br/>
<br/> Options: Flags to configure the client behavior. Defaults
<br/> are marked with *.
<br/>
<br/> allwrite Leaves all files writable on the client;
<br/> noallwrite * by default, only files opened by 'p4 edit'
<br/> are writable. If set, files might be clobbered
<br/> as a result of ignoring the clobber option
<br/> (see below).
<br/>
<br/> clobber Permits 'p4 sync' to overwrite writable
<br/> noclobber * files on the client. noclobber is ignored if
<br/> allwrite is set.
<br/>
<br/> compress Compresses data sent between the client
<br/> nocompress * and server to speed up slow connections.
<br/>
<br/> locked Allows only the client owner to use or change
<br/> unlocked * the client spec. Prevents the client spec from
<br/> being deleted or unloaded.
<br/>
<br/> modtime Causes 'p4 sync' and 'p4 submit' to preserve
<br/> nomodtime * file modification time, as with files with the
<br/> +m type modifier. (See 'p4 help filetypes'.)
<br/> With nomodtime, file timestamps are updated by
<br/> sync and submit operations.
<br/>
<br/> rmdir Makes 'p4 sync' attempt to delete a workspace
<br/> normdir * directory when all files in it are removed.
<br/>
<br/> SubmitOptions: Flags to change submit behavior.
<br/>
<br/> submitunchanged All open files are submitted (default).
<br/>
<br/> revertunchanged Files that have content, type, or resolved
<br/> changes are submitted. Unchanged files are
<br/> reverted.
<br/>
<br/> leaveunchanged Files that have content, type, or resolved
<br/> changes are submitted. Unchanged files are
<br/> moved to the default changelist.
<br/>
<br/> +reopen Can be appended to the submit option flag
<br/> to cause submitted files to be reopened in
<br/> the default changelist.
<br/> Example: submitunchanged+reopen
<br/>
<br/> LineEnd: Set line-ending character(s) for client text files.
<br/>
<br/> local mode that is native to the client (default).
<br/> unix linefeed: UNIX style.
<br/> mac carriage return: Macintosh style.
<br/> win carriage return-linefeed: Windows style.
<br/> share hybrid: writes UNIX style but reads UNIX,
<br/> Mac or Windows style.
<br/>
<br/> View: Maps files in the depot to files in your client
<br/> workspace. Defines the files that you want in your
<br/> client workspace and specifies where you want them
<br/> to reside. The default view maps all depot files
<br/> onto the client. See 'p4 help views' for view syntax.
<br/> A new view takes effect on the next 'p4 sync'.
<br/>
<br/> ChangeView: Restricts depot paths to a particular point in time.
<br/> Example: //depot/path/...@1000
<br/> Revisions submitted to the path after the specified
<br/> changelist will not be visible. Files matching a
<br/> ChangeView path may not be submitted.
<br/>
<br/> Stream: The stream to which this client's view will be dedicated.
<br/> (Files in stream paths can be submitted only by dedicated
<br/> stream clients.) When this optional field is set, the
<br/> View field will be automatically replaced by a stream
<br/> view as the client spec is saved.
<br/>
<br/> StreamAtChange:
<br/> Stream meta-data (for view creation) is versioned.
<br/> When StreamAtChange is set, the stream hierarchy is
<br/> constructed back-in-time to reproduce the view that was
<br/> available to clients in the past. With this field set
<br/> changes cannot be be submitted from the client.
<br/> StreamAtChange is optional; Stream must be set as well.
<br/>
<br/> ServerID: If set, restricts usage to the named server.
<br/> If unset, usage is allowed on the master server and on
<br/> any replicas of the master other than Edge Servers.
<br/>
<br/> Note: changing the client root does not actually move the client
<br/> files; you must relocate them manually. Similarly, changing
<br/> the 'LineEnd' option does not actually update the client files;
<br/> you can refresh them with 'p4 sync -f'.
<br/>
<br/> The -d flag deletes the specified spec, as long as the client
<br/> workspace has no opened files or pending changes. (See 'p4 help
<br/> opened'.) The -f flag forces the delete. The -Fs option used with -f
<br/> forces client deletion even when the user has shelved changes. In
<br/> this case, the shelved changes are left intact.
<br/>
<br/> The -o flag writes the named client spec to the standard output.
<br/> The user's editor is not invoked.
<br/>
<br/> The -i flag reads a client spec from the standard input. The
<br/> user's editor is not invoked.
<br/>
<br/> The -t template flag, where 'template' is the name of another client
<br/> spec, causes the View and Options fields to be replaced by those of
<br/> the template.
<br/>
<br/> The -f flag can force the updating of locked clients; normally
<br/> locked clients can only be modified by their owner. -f also allows
<br/> the last modified date to be set. The -f flag requires 'admin'
<br/> access granted by 'p4 protect'.
<br/>
<br/> The -s flag is used to switch an existing client spec's view without
<br/> invoking the editor. It can be used with -S to switch to a stream
<br/> view, or with -t to switch to a view defined in another client spec.
<br/> Switching views is not allowed in a client that has opened files.
<br/> The -f flag can be used with -s to force switching with opened files.
<br/> View switching has no effect on files in a client workspace until
<br/> 'p4 sync' is run.
<br/>
<br/> Without -s, the '-S stream' flag can be used to create a new client
<br/> spec dedicated to a stream. If the client spec already exists, and
<br/> -S is used without -s, an error occurs when the client is bound to
<br/> a different, or no stream. Using -S sets the new client's
<br/> Stream field. The special syntax '-S //a/stream@changelist' can
<br/> be used to set both Stream and StreamAtChange at the same time.
<br/>
<br/> The '-S stream' flag can be used with '-o -c change' to inspect an
<br/> old stream client view. It yields the client spec that would have
<br/> been created for the stream at the moment the change was recorded.
<br/>
<br/> A server of type 'build-server' (see 'p4 help server') is a replica
<br/> which supports build farm integration, and the 'p4 client' command
<br/> may be used to create or edit client workspaces on a build-server.
<br/> Such workspaces may issue the 'p4 sync' command, in addition to any
<br/> read-only command supported by the replica. For more information, run
<br/> 'p4 help buildserver'.
<br/>
<br/> When creating or editing a client workspace for a build-server,
<br/> the client specified by the optional 'name' argument, as well as the
<br/> client specified by the $P4CLIENT environment variable or via the
<br/> global '-c client' argument must not exist, or must be restricted
<br/> to this server; this command may not be used to create or edit a
<br/> workspace that is not restricted to this build-server.
<br/>
<br/>
<br/>
</remarks>
<example>
To update a client named main_ws:
<code>
Client c = Repository.GetClient("main_ws");
// change the description add add a MapEntry to the ViewMap
c.Description = "client for main dev. Adding tools path";
DepotPath left = new DepotPath("//depot/tools/...");
ClientPath right = new ClientPath("//main_ws/tools/...");
MapEntry line = new MapEntry(MapType.Include, left, right);
c.ViewMap.Add(line);
Repository.UpdateClient(c);
</code>
</example>
</member>
<member name="M:Perforce.P4.Repository.GetClient(System.String,Perforce.P4.Options)">
<summary>
Get the record for an existing client from the repository.
</summary>
<param name="client">Client name</param>
<param name="options">There are no valid flags to use when fetching an existing client</param>
<returns>The Client object if new client was found, null if creation failed</returns>
<summary>
Create a new client in the repository.
</summary>
<param name="client">Client specification for the new user</param>
<param name="options">The '-i' flags is required when creating a new user</param>
<returns>The Client object if new user was created, null if creation failed</returns>
<remarks> The '-i' flag is added if not specified by the caller
<br/>
<br/><b>p4 help client</b>
<br/>
<br/> client -- Create or edit a client workspace specification and its view
<br/> workspace -- Synonym for 'client'
<br/>
<br/> p4 client [-f] [-t template] [name]
<br/> p4 client -d [-f [-Fs]] name
<br/> p4 client -o [-t template] [name]
<br/> p4 client -S stream [[-c change] -o] [name]
<br/> p4 client -s [-f] -S stream [name]
<br/> p4 client -s [-f] -t template [name]
<br/> p4 client -i [-f]
<br/>
<br/> Creates a new client specification ('spec') or edits an existing
<br/> spec. A client spec is a named mapping of depot files to workspace
<br/> files.
<br/>
<br/> The 'p4 client' command puts the client spec into a temporary file
<br/> and invokes the editor configured by the environment variable
<br/> $P4EDITOR. For new workspaces, the client name defaults to the
<br/> $P4CLIENT environment variable, if set, or to the current host name.
<br/> Saving the file creates or modifies the client spec.
<br/>
<br/> The client spec contains the following fields:
<br/>
<br/> Client: The client name.
<br/>
<br/> Host: If set, restricts access to the named host.
<br/> If unset, access is allowed from any host.
<br/>
<br/> Owner: The user who created this client.
<br/>
<br/> Update: The date that this spec was last modified.
<br/>
<br/> Access: The date that this client was last used in any way.
<br/>
<br/> Description: A short description of the workspace.
<br/>
<br/> Root: The root directory of the workspace (specified in local
<br/> file system syntax), under which all versioned files
<br/> will be placed. If you change this setting, you must
<br/> physically relocate any files that currently reside
<br/> there. On Windows client machines, you can specify the
<br/> root as "null" to enable you to map files to multiple
<br/> drives.
<br/>
<br/> AltRoots: Up to two optional alternate client workspace roots.
<br/> The first of the main and alternate roots to match the
<br/> client program's current working directory is used. If
<br/> none match, the main root is used. 'p4 info' displays
<br/> the root that is being used.
<br/>
<br/> Options: Flags to configure the client behavior. Defaults
<br/> are marked with *.
<br/>
<br/> allwrite Leaves all files writable on the client;
<br/> noallwrite * by default, only files opened by 'p4 edit'
<br/> are writable. If set, files might be clobbered
<br/> as a result of ignoring the clobber option
<br/> (see below).
<br/>
<br/> clobber Permits 'p4 sync' to overwrite writable
<br/> noclobber * files on the client. noclobber is ignored if
<br/> allwrite is set.
<br/>
<br/> compress Compresses data sent between the client
<br/> nocompress * and server to speed up slow connections.
<br/>
<br/> locked Allows only the client owner to use or change
<br/> unlocked * the client spec. Prevents the client spec from
<br/> being deleted or unloaded.
<br/>
<br/> modtime Causes 'p4 sync' and 'p4 submit' to preserve
<br/> nomodtime * file modification time, as with files with the
<br/> +m type modifier. (See 'p4 help filetypes'.)
<br/> With nomodtime, file timestamps are updated by
<br/> sync and submit operations.
<br/>
<br/> rmdir Makes 'p4 sync' attempt to delete a workspace
<br/> normdir * directory when all files in it are removed.
<br/>
<br/> SubmitOptions: Flags to change submit behavior.
<br/>
<br/> submitunchanged All open files are submitted (default).
<br/>
<br/> revertunchanged Files that have content, type, or resolved
<br/> changes are submitted. Unchanged files are
<br/> reverted.
<br/>
<br/> leaveunchanged Files that have content, type, or resolved
<br/> changes are submitted. Unchanged files are
<br/> moved to the default changelist.
<br/>
<br/> +reopen Can be appended to the submit option flag
<br/> to cause submitted files to be reopened in
<br/> the default changelist.
<br/> Example: submitunchanged+reopen
<br/>
<br/> LineEnd: Set line-ending character(s) for client text files.
<br/>
<br/> local mode that is native to the client (default).
<br/> unix linefeed: UNIX style.
<br/> mac carriage return: Macintosh style.
<br/> win carriage return-linefeed: Windows style.
<br/> share hybrid: writes UNIX style but reads UNIX,
<br/> Mac or Windows style.
<br/>
<br/> View: Maps files in the depot to files in your client
<br/> workspace. Defines the files that you want in your
<br/> client workspace and specifies where you want them
<br/> to reside. The default view maps all depot files
<br/> onto the client. See 'p4 help views' for view syntax.
<br/> A new view takes effect on the next 'p4 sync'.
<br/>
<br/> ChangeView: Restricts depot paths to a particular point in time.
<br/> Example: //depot/path/...@1000
<br/> Revisions submitted to the path after the specified
<br/> changelist will not be visible. Files matching a
<br/> ChangeView path may not be submitted.
<br/>
<br/> Stream: The stream to which this client's view will be dedicated.
<br/> (Files in stream paths can be submitted only by dedicated
<br/> stream clients.) When this optional field is set, the
<br/> View field will be automatically replaced by a stream
<br/> view as the client spec is saved.
<br/>
<br/> StreamAtChange:
<br/> Stream meta-data (for view creation) is versioned.
<br/> When StreamAtChange is set, the stream hierarchy is
<br/> constructed back-in-time to reproduce the view that was
<br/> available to clients in the past. With this field set
<br/> changes cannot be be submitted from the client.
<br/> StreamAtChange is optional; Stream must be set as well.
<br/>
<br/> ServerID: If set, restricts usage to the named server.
<br/> If unset, usage is allowed on the master server and on
<br/> any replicas of the master other than Edge Servers.
<br/>
<br/> Note: changing the client root does not actually move the client
<br/> files; you must relocate them manually. Similarly, changing
<br/> the 'LineEnd' option does not actually update the client files;
<br/> you can refresh them with 'p4 sync -f'.
<br/>
<br/> The -d flag deletes the specified spec, as long as the client
<br/> workspace has no opened files or pending changes. (See 'p4 help
<br/> opened'.) The -f flag forces the delete. The -Fs option used with -f
<br/> forces client deletion even when the user has shelved changes. In
<br/> this case, the shelved changes are left intact.
<br/>
<br/> The -o flag writes the named client spec to the standard output.
<br/> The user's editor is not invoked.
<br/>
<br/> The -i flag reads a client spec from the standard input. The
<br/> user's editor is not invoked.
<br/>
<br/> The -t template flag, where 'template' is the name of another client
<br/> spec, causes the View and Options fields to be replaced by those of
<br/> the template.
<br/>
<br/> The -f flag can force the updating of locked clients; normally
<br/> locked clients can only be modified by their owner. -f also allows
<br/> the last modified date to be set. The -f flag requires 'admin'
<br/> access granted by 'p4 protect'.
<br/>
<br/> The -s flag is used to switch an existing client spec's view without
<br/> invoking the editor. It can be used with -S to switch to a stream
<br/> view, or with -t to switch to a view defined in another client spec.
<br/> Switching views is not allowed in a client that has opened files.
<br/> The -f flag can be used with -s to force switching with opened files.
<br/> View switching has no effect on files in a client workspace until
<br/> 'p4 sync' is run.
<br/>
<br/> Without -s, the '-S stream' flag can be used to create a new client
<br/> spec dedicated to a stream. If the client spec already exists, and
<br/> -S is used without -s, an error occurs when the client is bound to
<br/> a different, or no stream. Using -S sets the new client's
<br/> Stream field. The special syntax '-S //a/stream@changelist' can
<br/> be used to set both Stream and StreamAtChange at the same time.
<br/>
<br/> The '-S stream' flag can be used with '-o -c change' to inspect an
<br/> old stream client view. It yields the client spec that would have
<br/> been created for the stream at the moment the change was recorded.
<br/>
<br/> A server of type 'build-server' (see 'p4 help server') is a replica
<br/> which supports build farm integration, and the 'p4 client' command
<br/> may be used to create or edit client workspaces on a build-server.
<br/> Such workspaces may issue the 'p4 sync' command, in addition to any
<br/> read-only command supported by the replica. For more information, run
<br/> 'p4 help buildserver'.
<br/>
<br/> When creating or editing a client workspace for a build-server,
<br/> the client specified by the optional 'name' argument, as well as the
<br/> client specified by the $P4CLIENT environment variable or via the
<br/> global '-c client' argument must not exist, or must be restricted
<br/> to this server; this command may not be used to create or edit a
<br/> workspace that is not restricted to this build-server.
<br/>
<br/>
<br/>
</remarks>
<example>
To get the spec for a client named main_ws:
<code>
Client c = Repository.GetClient("main_ws", null);
</code>
</example>
<seealso cref="T:Perforce.P4.ClientCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.GetClient(System.String)">
<summary>
Get the record for an existing client from the repository.
</summary>
<param name="client">Client name</param>
<param name="options">There are no valid flags to use when fetching an existing client</param>
<returns>The Client object if new client was found, null if creation failed</returns>
<summary>
Create a new client in the repository.
</summary>
<param name="client">Client specification for the new user</param>
<param name="options">The '-i' flags is required when creating a new user</param>
<returns>The Client object if new user was created, null if creation failed</returns>
<remarks> The '-i' flag is added if not specified by the caller
<br/>
<br/><b>p4 help client</b>
<br/>
<br/> client -- Create or edit a client workspace specification and its view
<br/> workspace -- Synonym for 'client'
<br/>
<br/> p4 client [-f] [-t template] [name]
<br/> p4 client -d [-f [-Fs]] name
<br/> p4 client -o [-t template] [name]
<br/> p4 client -S stream [[-c change] -o] [name]
<br/> p4 client -s [-f] -S stream [name]
<br/> p4 client -s [-f] -t template [name]
<br/> p4 client -i [-f]
<br/>
<br/> Creates a new client specification ('spec') or edits an existing
<br/> spec. A client spec is a named mapping of depot files to workspace
<br/> files.
<br/>
<br/> The 'p4 client' command puts the client spec into a temporary file
<br/> and invokes the editor configured by the environment variable
<br/> $P4EDITOR. For new workspaces, the client name defaults to the
<br/> $P4CLIENT environment variable, if set, or to the current host name.
<br/> Saving the file creates or modifies the client spec.
<br/>
<br/> The client spec contains the following fields:
<br/>
<br/> Client: The client name.
<br/>
<br/> Host: If set, restricts access to the named host.
<br/> If unset, access is allowed from any host.
<br/>
<br/> Owner: The user who created this client.
<br/>
<br/> Update: The date that this spec was last modified.
<br/>
<br/> Access: The date that this client was last used in any way.
<br/>
<br/> Description: A short description of the workspace.
<br/>
<br/> Root: The root directory of the workspace (specified in local
<br/> file system syntax), under which all versioned files
<br/> will be placed. If you change this setting, you must
<br/> physically relocate any files that currently reside
<br/> there. On Windows client machines, you can specify the
<br/> root as "null" to enable you to map files to multiple
<br/> drives.
<br/>
<br/> AltRoots: Up to two optional alternate client workspace roots.
<br/> The first of the main and alternate roots to match the
<br/> client program's current working directory is used. If
<br/> none match, the main root is used. 'p4 info' displays
<br/> the root that is being used.
<br/>
<br/> Options: Flags to configure the client behavior. Defaults
<br/> are marked with *.
<br/>
<br/> allwrite Leaves all files writable on the client;
<br/> noallwrite * by default, only files opened by 'p4 edit'
<br/> are writable. If set, files might be clobbered
<br/> as a result of ignoring the clobber option
<br/> (see below).
<br/>
<br/> clobber Permits 'p4 sync' to overwrite writable
<br/> noclobber * files on the client. noclobber is ignored if
<br/> allwrite is set.
<br/>
<br/> compress Compresses data sent between the client
<br/> nocompress * and server to speed up slow connections.
<br/>
<br/> locked Allows only the client owner to use or change
<br/> unlocked * the client spec. Prevents the client spec from
<br/> being deleted or unloaded.
<br/>
<br/> modtime Causes 'p4 sync' and 'p4 submit' to preserve
<br/> nomodtime * file modification time, as with files with the
<br/> +m type modifier. (See 'p4 help filetypes'.)
<br/> With nomodtime, file timestamps are updated by
<br/> sync and submit operations.
<br/>
<br/> rmdir Makes 'p4 sync' attempt to delete a workspace
<br/> normdir * directory when all files in it are removed.
<br/>
<br/> SubmitOptions: Flags to change submit behavior.
<br/>
<br/> submitunchanged All open files are submitted (default).
<br/>
<br/> revertunchanged Files that have content, type, or resolved
<br/> changes are submitted. Unchanged files are
<br/> reverted.
<br/>
<br/> leaveunchanged Files that have content, type, or resolved
<br/> changes are submitted. Unchanged files are
<br/> moved to the default changelist.
<br/>
<br/> +reopen Can be appended to the submit option flag
<br/> to cause submitted files to be reopened in
<br/> the default changelist.
<br/> Example: submitunchanged+reopen
<br/>
<br/> LineEnd: Set line-ending character(s) for client text files.
<br/>
<br/> local mode that is native to the client (default).
<br/> unix linefeed: UNIX style.
<br/> mac carriage return: Macintosh style.
<br/> win carriage return-linefeed: Windows style.
<br/> share hybrid: writes UNIX style but reads UNIX,
<br/> Mac or Windows style.
<br/>
<br/> View: Maps files in the depot to files in your client
<br/> workspace. Defines the files that you want in your
<br/> client workspace and specifies where you want them
<br/> to reside. The default view maps all depot files
<br/> onto the client. See 'p4 help views' for view syntax.
<br/> A new view takes effect on the next 'p4 sync'.
<br/>
<br/> ChangeView: Restricts depot paths to a particular point in time.
<br/> Example: //depot/path/...@1000
<br/> Revisions submitted to the path after the specified
<br/> changelist will not be visible. Files matching a
<br/> ChangeView path may not be submitted.
<br/>
<br/> Stream: The stream to which this client's view will be dedicated.
<br/> (Files in stream paths can be submitted only by dedicated
<br/> stream clients.) When this optional field is set, the
<br/> View field will be automatically replaced by a stream
<br/> view as the client spec is saved.
<br/>
<br/> StreamAtChange:
<br/> Stream meta-data (for view creation) is versioned.
<br/> When StreamAtChange is set, the stream hierarchy is
<br/> constructed back-in-time to reproduce the view that was
<br/> available to clients in the past. With this field set
<br/> changes cannot be be submitted from the client.
<br/> StreamAtChange is optional; Stream must be set as well.
<br/>
<br/> ServerID: If set, restricts usage to the named server.
<br/> If unset, usage is allowed on the master server and on
<br/> any replicas of the master other than Edge Servers.
<br/>
<br/> Note: changing the client root does not actually move the client
<br/> files; you must relocate them manually. Similarly, changing
<br/> the 'LineEnd' option does not actually update the client files;
<br/> you can refresh them with 'p4 sync -f'.
<br/>
<br/> The -d flag deletes the specified spec, as long as the client
<br/> workspace has no opened files or pending changes. (See 'p4 help
<br/> opened'.) The -f flag forces the delete. The -Fs option used with -f
<br/> forces client deletion even when the user has shelved changes. In
<br/> this case, the shelved changes are left intact.
<br/>
<br/> The -o flag writes the named client spec to the standard output.
<br/> The user's editor is not invoked.
<br/>
<br/> The -i flag reads a client spec from the standard input. The
<br/> user's editor is not invoked.
<br/>
<br/> The -t template flag, where 'template' is the name of another client
<br/> spec, causes the View and Options fields to be replaced by those of
<br/> the template.
<br/>
<br/> The -f flag can force the updating of locked clients; normally
<br/> locked clients can only be modified by their owner. -f also allows
<br/> the last modified date to be set. The -f flag requires 'admin'
<br/> access granted by 'p4 protect'.
<br/>
<br/> The -s flag is used to switch an existing client spec's view without
<br/> invoking the editor. It can be used with -S to switch to a stream
<br/> view, or with -t to switch to a view defined in another client spec.
<br/> Switching views is not allowed in a client that has opened files.
<br/> The -f flag can be used with -s to force switching with opened files.
<br/> View switching has no effect on files in a client workspace until
<br/> 'p4 sync' is run.
<br/>
<br/> Without -s, the '-S stream' flag can be used to create a new client
<br/> spec dedicated to a stream. If the client spec already exists, and
<br/> -S is used without -s, an error occurs when the client is bound to
<br/> a different, or no stream. Using -S sets the new client's
<br/> Stream field. The special syntax '-S //a/stream@changelist' can
<br/> be used to set both Stream and StreamAtChange at the same time.
<br/>
<br/> The '-S stream' flag can be used with '-o -c change' to inspect an
<br/> old stream client view. It yields the client spec that would have
<br/> been created for the stream at the moment the change was recorded.
<br/>
<br/> A server of type 'build-server' (see 'p4 help server') is a replica
<br/> which supports build farm integration, and the 'p4 client' command
<br/> may be used to create or edit client workspaces on a build-server.
<br/> Such workspaces may issue the 'p4 sync' command, in addition to any
<br/> read-only command supported by the replica. For more information, run
<br/> 'p4 help buildserver'.
<br/>
<br/> When creating or editing a client workspace for a build-server,
<br/> the client specified by the optional 'name' argument, as well as the
<br/> client specified by the $P4CLIENT environment variable or via the
<br/> global '-c client' argument must not exist, or must be restricted
<br/> to this server; this command may not be used to create or edit a
<br/> workspace that is not restricted to this build-server.
<br/>
<br/>
<br/>
</remarks>
<example>
To get the spec for a client named main_ws:
<code>
Client c = Repository.GetClient("main_ws");
</code>
</example>
</member>
<member name="M:Perforce.P4.Repository.GetClients(Perforce.P4.Options)">
<summary>
Get a list of clients from the repository
</summary>
<param name="options">options for the clients command<see cref="T:Perforce.P4.ClientsCmdOptions"/></param>
<returns>A list containing the matching clients</returns>
<remarks>
<br/><b>p4 help clients</b>
<br/>
<br/> clients -- Display list of clients
<br/> workspaces -- synonym for 'clients'
<br/>
<br/> p4 clients [-t] [-u user] [[-e|-E] nameFilter -m max] [-S stream]
<br/> [-a | -s serverID]
<br/> p4 clients -U
<br/>
<br/> Lists all client workspaces currently defined in the server.
<br/>
<br/> The -t flag displays the time as well as the date.
<br/>
<br/> The -u user flag lists client workspaces that are owned by the
<br/> specified user.
<br/>
<br/> The -e nameFilter flag lists workspaces with a name that matches
<br/> the nameFilter pattern, for example: -e 'svr-dev-rel*'. The -e flag
<br/> uses the server's normal case-sensitivity rules. The -E flag makes
<br/> the matching case-insensitive, even on a case-sensitive server.
<br/>
<br/> The -m max flag limits output to the specified number of workspaces.
<br/>
<br/> The -S stream flag limits output to the client workspaces dedicated
<br/> to the stream.
<br/>
<br/> The -U flag lists unloaded clients (see 'p4 help unload').
<br/>
<br/> The -a flag specifies that all clients should be displayed, not just
<br/> those that are bound to this server.
<br/>
<br/> The -s serverID flag specifies that only those clients bound to the
<br/> specified serverID should be displayed. On an Edge Server, the -s
<br/> flag defaults to the Edge Server's serverID.
<br/>
<br/>
<br/>
</remarks>
<example>
To get a list of a maximum of 10 clients:
<code>
ClientsCmdOptions opts =
new ClientsCmdOptions(ClientsCmdFlags.NoneIncludeTime, null, null, 10, null));
IList<Client> clients = Repository.GetClients(opts);
</code>
To get a list of clients that have "iOS_app" in their name:
<code>
ClientsCmdOptions opts =
new ClientsCmdOptions(ClientsCmdFlags.NoneIncludeTime, null, "*iOS_app*, 0, null));
IList<Client> clients = Repository.GetClients(opts);
</code>
To get a list of clients that can be used with stream //depot/main:
<code>
ClientsCmdOptions opts =
new ClientsCmdOptions(ClientsCmdFlags.NoneIncludeTime, null, null, 0, "//depot/main"));
IList<Client> clients = Repository.GetClients(opts);
</code>
To get a list clients owned by user bsmith:
<code>
ClientsCmdOptions opts =
new ClientsCmdOptions(ClientsCmdFlags.NoneIncludeTime, "bsmith", null, 0, null));
IList<Client> clients = Repository.GetClients(opts);
</code>
</example>
<seealso cref="T:Perforce.P4.ClientsCmdOptions"/>
</member>
<member name="M:Perforce.P4.Repository.DeleteClient(Perforce.P4.Client,Perforce.P4.Options)">
<summary>
Delete a client from the repository
</summary>
<param name="client">The client to be deleted</param>
<param name="options">Only the '-f' flag is valid when deleting an existing client</param>
<remarks>
<br/>
<br/><b>p4 help client</b>
<br/>
<br/> client -- Create or edit a client workspace specification and its view
<br/> workspace -- Synonym for 'client'
<br/>
<br/> p4 client [-f] [-t template] [name]
<br/> p4 client -d [-f [-Fs]] name
<br/> p4 client -o [-t template] [name]
<br/> p4 client -S stream [[-c change] -o] [name]
<br/> p4 client -s [-f] -S stream [name]
<br/> p4 client -s [-f] -t template [name]
<br/> p4 client -i [-f]
<br/>
<br/> Creates a new client specification ('spec') or edits an existing
<br/> spec. A client spec is a named mapping of depot files to workspace
<br/> files.
<br/>
<br/> The 'p4 client' command puts the client spec into a temporary file
<br/> and invokes the editor configured by the environment variable
<br/> $P4EDITOR. For new workspaces, the client name defaults to the
<br/> $P4CLIENT environment variable, if set, or to the current host name.
<br/> Saving the file creates or modifies the client spec.
<br/>
<br/> The client spec contains the following fields:
<br/>
<br/> Client: The client name.
<br/>
<br/> Host: If set, restricts access to the named host.
<br/> If unset, access is allowed from any host.
<br/>
<br/> Owner: The user who created this client.
<br/>
<br/> Update: The date that this spec was last modified.
<br/>
<br/> Access: The date that this client was last used in any way.
<br/>
<br/> Description: A short description of the workspace.
<br/>
<br/> Root: The root directory of the workspace (specified in local
<br/> file system syntax), under which all versioned files
<br/> will be placed. If you change this setting, you must
<br/> physically relocate any files that currently reside
<br/> there. On Windows client machines, you can specify the
<br/> root as "null" to enable you to map files to multiple
<br/> drives.
<br/>
<br/> AltRoots: Up to two optional alternate client workspace roots.
<br/> The first of the main and alternate roots to match the
<br/> client program's current working directory is used. If
<br/> none match, the main root is used. 'p4 info' displays
<br/> the root that is being used.
<br/>
<br/> Options: Flags to configure the client behavior. Defaults
<br/> are marked with *.
<br/>
<br/> allwrite Leaves all files writable on the client;
<br/> noallwrite * by default, only files opened by 'p4 edit'
<br/> are writable. If set, files might be clobbered
<br/> as a result of ignoring the clobber option
<br/> (see below).
<br/>
<br/> clobber Permits 'p4 sync' to overwrite writable
<br/> noclobber * files on the client. noclobber is ignored if
<br/> allwrite is set.
<br/>
<br/> compress Compresses data sent between the client
<br/> nocompress * and server to speed up slow connections.
<br/>
<br/> locked Allows only the client owner to use or change
<br/> unlocked * the client spec. Prevents the client spec from
<br/> being deleted or unloaded.
<br/>
<br/> modtime Causes 'p4 sync' and 'p4 submit' to preserve
<br/> nomodtime * file modification time, as with files with the
<br/> +m type modifier. (See 'p4 help filetypes'.)
<br/> With nomodtime, file timestamps are updated by
<br/> sync and submit operations.
<br/>
<br/> rmdir Makes 'p4 sync' attempt to delete a workspace
<br/> normdir * directory when all files in it are removed.
<br/>
<br/> SubmitOptions: Flags to change submit behavior.
<br/>
<br/> submitunchanged All open files are submitted (default).
<br/>
<br/> revertunchanged Files that have content, type, or resolved
<br/> changes are submitted. Unchanged files are
<br/> reverted.
<br/>
<br/> leaveunchanged Files that have content, type, or resolved
<br/> changes are submitted. Unchanged files are
<br/> moved to the default changelist.
<br/>
<br/> +reopen Can be appended to the submit option flag
<br/> to cause submitted files to be reopened in
<br/> the default changelist.
<br/> Example: submitunchanged+reopen
<br/>
<br/> LineEnd: Set line-ending character(s) for client text files.
<br/>
<br/> local mode that is native to the client (default).
<br/> unix linefeed: UNIX style.
<br/> mac carriage return: Macintosh style.
<br/> win carriage return-linefeed: Windows style.
<br/> share hybrid: writes UNIX style but reads UNIX,
<br/> Mac or Windows style.
<br/>
<br/> View: Maps files in the depot to files in your client
<br/> workspace. Defines the files that you want in your
<br/> client workspace and specifies where you want them
<br/> to reside. The default view maps all depot files
<br/> onto the client. See 'p4 help views' for view syntax.
<br/> A new view takes effect on the next 'p4 sync'.
<br/>
<br/> ChangeView: Restricts depot paths to a particular point in time.
<br/> Example: //depot/path/...@1000
<br/> Revisions submitted to the path after the specified
<br/> changelist will not be visible. Files matching a
<br/> ChangeView path may not be submitted.
<br/>
<br/> Stream: The stream to which this client's view will be dedicated.
<br/> (Files in stream paths can be submitted only by dedicated
<br/> stream clients.) When this optional field is set, the
<br/> View field will be automatically replaced by a stream
<br/> view as the client spec is saved.
<br/>
<br/> StreamAtChange:
<br/> Stream meta-data (for view creation) is versioned.
<br/> When StreamAtChange is set, the stream hierarchy is
<br/> constructed back-in-time to reproduce the view that was
<br/> available to clients in the past. With this field set
<br/> changes cannot be be submitted from the client.
<br/> StreamAtChange is optional; Stream must be set as well.
<br/>
<br/> ServerID: If set, restricts usage to the named server.
<br/> If unset, usage is allowed on the master server and on
<br/> any replicas of the master other than Edge Servers.
<br/>
<br/> Note: changing the client root does not actually move the client
<br/> files; you must relocate them manually. Similarly, changing
<br/> the 'LineEnd' option does not actually update the client files;
<br/> you can refresh them with 'p4 sync -f'.
<br/>
<br/> The -d flag deletes the specified spec, as long as the client
<br/> workspace has no opened files or pending changes. (See 'p4 help
<br/> opened'.) The -f flag forces the delete. The -Fs option used with -f
<br/> forces client deletion even when the user has shelved changes. In
<br/> this case, the shelved changes are left intact.
<br/>
<br/> The -o flag writes the named client spec to the standard output.
<br/> The user's editor is not invoked.
<br/>
<br/> The -i flag reads a client spec from the standard input. The
<br/> user's editor is not invoked.
<br/>
<br/> The -t template flag, where 'template' is the name of another client
<br/> spec, causes the View and Options fields to be replaced by those of
<br/> the template.
<br/>
<br/> The -f flag can force the updating of locked clients; normally
<br/> locked clients can only be modified by their owner. -f also allows
<br/> the last modified date to be set. The -f flag requires 'admin'
<br/> access granted by 'p4 protect'.
<br/>
<br/> The -s flag is used to switch an existing client spec's view without
<br/> invoking the editor. It can be used with -S to switch to a stream
<br/> view, or with -t to switch to a view defined in another client spec.
<br/> Switching views is not allowed in a client that has opened files.
<br/> The -f flag can be used with -s to force switching with opened files.
<br/> View switching has no effect on files in a client workspace until
<br/> 'p4 sync' is run.
<br/>
<br/> Without -s, the '-S stream' flag can be used to create a new client
<br/> spec dedicated to a stream. If the client spec already exists, and
<br/> -S is used without -s, an error occurs when the client is bound to
<br/> a different, or no stream. Using -S sets the new client's
<br/> Stream field. The special syntax '-S //a/stream@changelist' can
<br/> be used to set both Stream and StreamAtChange at the same time.
<br/>
<br/> The '-S stream' flag can be used with '-o -c change' to inspect an
<br/> old stream client view. It yields the client spec that would have
<br/> been created for the stream at the moment the change was recorded.
<br/>
<br/> A server of type 'build-server' (see 'p4 help server') is a replica
<br/> which supports build farm integration, and the 'p4 client' command
<br/> may be used to create or edit client workspaces on a build-server.
<br/> Such workspaces may issue the 'p4 sync' command, in addition to any
<br/> read-only command supported by the replica. For more information, run
<br/> 'p4 help buildserver'.
<br/>
<br/> When creating or editing a client workspace for a build-server,
<br/> the client specified by the optional 'name' argument, as well as the
<br/> client specified by the $P4CLIENT environment variable or via the
<br/> global '-c client' argument must not exist, or must be restricted
<br/> to this server; this command may not be used to create or edit a
<br/> workspace that is not restricted to this build-server.
<br/>
<br/>
<br/>
</remarks>
<example>
To delete a client named main_ws with the user who owns it:
<code>
Client c = Repository.GetClient("main_ws");
Repository.DeleteClient(c, null);
</code>
To delete a locked client named main_ws with an admin user:
<code>
Client c = Repository.GetClient("main_ws", null);
ClientCmdOptions opts = new ClientCmdOptions(ClientCmdFlags.Force);
rep.DeleteClient(c, opts);
</code>
</example>
<seealso cref="T:Perforce.P4.ClientCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.#ctor(Perforce.P4.Server)">
<summary>
Create a repository on the specified server.
</summary>
<param name="server">The repository server.</param>
</member>
<member name="M:Perforce.P4.Repository.GetDepotFiles(System.Collections.Generic.IList{Perforce.P4.FileSpec},Perforce.P4.Options)">
<summary>
Return a list of FileSpecs of files in the depot that correspond
to the passed-in FileSpecs.
</summary>
<param name="filespecs"></param>
<param name="options"></param>
<returns></returns>
<remarks>
<br/><b>p4 help files</b>
<br/>
<br/> files -- List files in the depot
<br/>
<br/> p4 files [ -a ] [ -A ] [ -e ] [ -m max ] file[revRange] ...
<br/> p4 files -U unloadfile ...
<br/>
<br/> List details about specified files: depot file name, revision,
<br/> file, type, change action and changelist number of the current
<br/> head revision. If client syntax is used to specify the file
<br/> argument, the client view mapping is used to determine the
<br/> corresponding depot files.
<br/>
<br/> By default, the head revision is listed. If the file argument
<br/> specifies a revision, then all files at that revision are listed.
<br/> If the file argument specifies a revision range, the highest revision
<br/> in the range is used for each file. For details about specifying
<br/> revisions, see 'p4 help revisions'.
<br/>
<br/> The -a flag displays all revisions within the specific range, rather
<br/> than just the highest revision in the range.
<br/>
<br/> The -A flag displays files in archive depots.
<br/>
<br/> The -e flag displays files with an action of anything other than
<br/> deleted, purged or archived. Typically this revision is always
<br/> available to sync or integrate from.
<br/>
<br/> The -m flag limits files to the first 'max' number of files.
<br/>
<br/> The -U option displays files in the unload depot (see 'p4 help unload'
<br/> for more information about the unload depot).
<br/>
<br/>
</remarks>
<example>
To get a maximum of 10 files from the repository:
<code>
GetDepotFilesCmdOptions opts =
new GetDepotFilesCmdOptions(GetDepotFilesCmdFlags.None, 10);
FileSpec fs = new FileSpec(new DepotPath("//depot/..."), null);
List<FileSpec> lfs = new List<FileSpec>();
lfs.Add(fs);
IList<FileSpec> files = Repository.GetDepotFiles(lfs, opts);
</code>
</example>
<seealso cref="T:Perforce.P4.GetDepotFilesCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.GetOpenedFiles(System.Collections.Generic.IList{Perforce.P4.FileSpec},Perforce.P4.Options)">
<summary>
Return a list of Files opened by users / clients.
</summary>
<param name="filespecs"></param>
<param name="options"></param>
<returns></returns>
<remarks>
<br/><b>p4 help opened</b>
<br/>
<br/> opened -- List open files and display file status
<br/>
<br/> p4 opened [-a -c changelist# -C client -u user -m max -s] [file ...]
<br/> p4 opened [-a -x -m max ] [file ...]
<br/>
<br/> Lists files currently opened in pending changelists, or, for
<br/> specified files, show whether they are currently opened or locked.
<br/> If the file specification is omitted, all files open in the current
<br/> client workspace are listed.
<br/>
<br/> Files in shelved changelists are not displayed by this command. To
<br/> display shelved changelists, see 'p4 changes -s shelved'; to display
<br/> the files in those shelved changelists, see 'p4 describe -s -S'.
<br/>
<br/> The -a flag lists opened files in all clients. By default, only
<br/> files opened by the current client are listed.
<br/>
<br/> The -c changelist# flag lists files opened in the specified
<br/> changelist#.
<br/>
<br/> The -C client flag lists files open in the specified client workspace.
<br/>
<br/> The -u user flag lists files opened by the specified user.
<br/>
<br/> The -m max flag limits output to the first 'max' number of files.
<br/>
<br/> The -s option produces 'short' and optimized output when used with
<br/> the -a (all clients) option. For large repositories '-a' can take
<br/> a long time when compared to '-as'.
<br/>
<br/> The -x option lists files that are opened 'exclusive'. This option
<br/> only applies to a distributed installation where global tracking of
<br/> these file types is necessary across servers. The -x option implies
<br/> the -a option.
<br/>
<br/>
</remarks>
<example>
To get a maximum of 10 opened files from the repository, opened by
user fred, opened with any client:
<code>
FileSpec fs = new FileSpec(new DepotPath("//..."), null);
List<FileSpec> lfs = new List<FileSpec>();
lfs.Add(fs);
// null for changelist and client options
GetOpenedFilesOptions opts =
new GetOpenedFilesOptions(GetOpenedFilesCmdFlags.AllClients,
null, null, "fred", 10);
IList<File> target = Repository.GetOpenedFiles(lfs, opts);
</code>
</example>
<seealso cref="T:Perforce.P4.GetOpenedFilesCmdFlags"/>
</member>
<!-- Badly formed XML comment ignored for member "M:Perforce.P4.Repository.GetFileMetaData(Perforce.P4.Options,Perforce.P4.FileSpec[])" -->
<!-- Badly formed XML comment ignored for member "M:Perforce.P4.Repository.GetFileMetaData(System.Collections.Generic.IList{Perforce.P4.FileSpec},Perforce.P4.Options)" -->
<member name="M:Perforce.P4.Repository.GetFiles(Perforce.P4.Options,Perforce.P4.FileSpec[])">
<summary>
Return a list of Files in the depot that correspond to the passed-in
FileSpecs.
</summary>
<remarks>
<br/><b>p4 help files</b>
<br/>
<br/> files -- List files in the depot
<br/>
<br/> p4 files [ -a ] [ -A ] [ -e ] [ -m max ] file[revRange] ...
<br/> p4 files -U unloadfile ...
<br/>
<br/> List details about specified files: depot file name, revision,
<br/> file, type, change action and changelist number of the current
<br/> head revision. If client syntax is used to specify the file
<br/> argument, the client view mapping is used to determine the
<br/> corresponding depot files.
<br/>
<br/> By default, the head revision is listed. If the file argument
<br/> specifies a revision, then all files at that revision are listed.
<br/> If the file argument specifies a revision range, the highest revision
<br/> in the range is used for each file. For details about specifying
<br/> revisions, see 'p4 help revisions'.
<br/>
<br/> The -a flag displays all revisions within the specific range, rather
<br/> than just the highest revision in the range.
<br/>
<br/> The -A flag displays files in archive depots.
<br/>
<br/> The -e flag displays files with an action of anything other than
<br/> deleted, purged or archived. Typically this revision is always
<br/> available to sync or integrate from.
<br/>
<br/> The -m flag limits files to the first 'max' number of files.
<br/>
<br/> The -U option displays files in the unload depot (see 'p4 help unload'
<br/> for more information about the unload depot).
<br/>
<br/>
</remarks>
<example>
To get Files in local depot //depot/...:
<code>
GetDepotFilesCmdOptions opts =
new GetDepotFilesCmdOptions(GetDepotFilesCmdFlags.None, 0);
FileSpec fs = new FileSpec(new DepotPath("//depot/..."), null);
IList<File> target = Repository.GetFiles(opts, fs);
</code>
To get Files in unload depot //Unloaded/...:
<code>
GetDepotFilesCmdOptions opts =
new GetDepotFilesCmdOptions(GetDepotFilesCmdFlags.InUnloadDepot, 0);
FileSpec fs = new FileSpec(new DepotPath("//Unloaded/..."), null);
IList<File> target = Repository.GetFiles(opts, fs);
</code>
</example>
<seealso cref="T:Perforce.P4.GetDepotFilesCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.GetFiles(System.Collections.Generic.IList{Perforce.P4.FileSpec},Perforce.P4.Options)">
<summary>
Return a list of Files in the depot that correspond to the passed-in
FileSpecs.
</summary>
<remarks>
<br/><b>p4 help files</b>
<br/>
<br/> files -- List files in the depot
<br/>
<br/> p4 files [ -a ] [ -A ] [ -e ] [ -m max ] file[revRange] ...
<br/> p4 files -U unloadfile ...
<br/>
<br/> List details about specified files: depot file name, revision,
<br/> file, type, change action and changelist number of the current
<br/> head revision. If client syntax is used to specify the file
<br/> argument, the client view mapping is used to determine the
<br/> corresponding depot files.
<br/>
<br/> By default, the head revision is listed. If the file argument
<br/> specifies a revision, then all files at that revision are listed.
<br/> If the file argument specifies a revision range, the highest revision
<br/> in the range is used for each file. For details about specifying
<br/> revisions, see 'p4 help revisions'.
<br/>
<br/> The -a flag displays all revisions within the specific range, rather
<br/> than just the highest revision in the range.
<br/>
<br/> The -A flag displays files in archive depots.
<br/>
<br/> The -e flag displays files with an action of anything other than
<br/> deleted, purged or archived. Typically this revision is always
<br/> available to sync or integrate from.
<br/>
<br/> The -m flag limits files to the first 'max' number of files.
<br/>
<br/> The -U option displays files in the unload depot (see 'p4 help unload'
<br/> for more information about the unload depot).
<br/>
<br/>
</remarks>
<example>
To get Files in local depot //depot/...:
<code>
FileSpec fs = new FileSpec(new DepotPath("//depot/..."), null);
IList<FileSpec> lfs = new List<FileSpec>();
lfs.Add(fs);
GetDepotFilesCmdOptions opts =
new GetDepotFilesCmdOptions(GetDepotFilesCmdFlags.None, 0);
IList<File> target = Repository.GetFiles(lfs, opts);
</code>
To get Files in unload depot //Unloaded/...:
<code>
FileSpec fs = new FileSpec(new DepotPath("//Unloaded/..."), null);
IList<FileSpec> lfs = new List<FileSpec>();
lfs.Add(fs);
GetDepotFilesCmdOptions opts =
new GetDepotFilesCmdOptions(GetDepotFilesCmdFlags.InUnloadDepot, 0);
IList<File> target = Repository.GetFiles(lfs, opts);
</code>
</example>
<seealso cref="T:Perforce.P4.GetDepotFilesCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.GetDepotDirs(Perforce.P4.Options,System.String[])">
<summary>
List selected directory paths in the repository.
</summary>
<param name="dirs"></param>
<param name="options"></param>
<returns></returns>
<remarks>
<br/><b>p4 help dirs</b>
<br/>
<br/> dirs -- List depot subdirectories
<br/>
<br/> p4 dirs [-C -D -H] [-S stream] dir[revRange] ...
<br/>
<br/> List directories that match the specified file pattern (dir).
<br/> This command does not support the recursive wildcard (...).
<br/> Use the * wildcard instead.
<br/>
<br/> Perforce does not track directories individually. A path is treated
<br/> as a directory if there are any undeleted files with that path as a
<br/> prefix.
<br/>
<br/> By default, all directories containing files are listed. If the dir
<br/> argument includes a revision range, only directories containing files
<br/> in the range are listed. For details about specifying file revisions,
<br/> see 'p4 help revisions'.
<br/>
<br/> The -C flag lists only directories that fall within the current
<br/> client view.
<br/>
<br/> The -D flag includes directories containing only deleted files.
<br/>
<br/> The -H flag lists directories containing files synced to the current
<br/> client workspace.
<br/>
<br/> The -S flag limits output to depot directories mapped in a stream's
<br/> client view.
<br/>
<br/>
</remarks>
<example>
To get dirs on the server that fall within the current client view:
<code>
GetDepotDirsCmdOptions opts =
new GetDepotDirsCmdOptions(GetDepotDirsCmdFlags.CurrentClientOnly, null);
IList<String> target = Repository.GetDepotDirs(opts, "//* );
</code>
To get dirs on the server that contain files synced to the current
client workspace:
<code>
GetDepotDirsCmdOptions opts =
new GetDepotDirsCmdOptions(GetDepotDirsCmdFlags.SyncedDirs, null);
IList<String> target = Repository.GetDepotDirs(opts, "//* );
</code>
To get dirs on the server that fall under the path //depot/main/:
<code>
GetDepotDirsCmdOptions opts =
new GetDepotDirsCmdOptions(GetDepotDirsCmdFlags.None, null);
IList<String> target = Repository.GetDepotDirs(opts, "//depot/main/* );
</code>
</example>
<seealso cref="T:Perforce.P4.GetDepotDirsCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.GetDepotDirs(System.Collections.Generic.IList{System.String},Perforce.P4.Options)">
<summary>
List selected directory paths in the repository.
</summary>
<param name="dirs"></param>
<param name="options"></param>
<returns></returns>
<remarks>
<br/><b>p4 help dirs</b>
<br/>
<br/> dirs -- List depot subdirectories
<br/>
<br/> p4 dirs [-C -D -H] [-S stream] dir[revRange] ...
<br/>
<br/> List directories that match the specified file pattern (dir).
<br/> This command does not support the recursive wildcard (...).
<br/> Use the * wildcard instead.
<br/>
<br/> Perforce does not track directories individually. A path is treated
<br/> as a directory if there are any undeleted files with that path as a
<br/> prefix.
<br/>
<br/> By default, all directories containing files are listed. If the dir
<br/> argument includes a revision range, only directories containing files
<br/> in the range are listed. For details about specifying file revisions,
<br/> see 'p4 help revisions'.
<br/>
<br/> The -C flag lists only directories that fall within the current
<br/> client view.
<br/>
<br/> The -D flag includes directories containing only deleted files.
<br/>
<br/> The -H flag lists directories containing files synced to the current
<br/> client workspace.
<br/>
<br/> The -S flag limits output to depot directories mapped in a stream's
<br/> client view.
<br/>
<br/>
</remarks>
<example>
To get dirs on the server that fall within the current client view:
<code>
GetDepotDirsCmdOptions opts =
new GetDepotDirsCmdOptions(GetDepotDirsCmdFlags.CurrentClientOnly, null);
IList<String> dirs = new List<String>()
dirs.Add("//*");
IList<String> target = Repository.GetDepotDirs(dirs, opts);
</code>
To get dirs on the server that contain files synced to the current
client workspace:
<code>
GetDepotDirsCmdOptions opts =
new GetDepotDirsCmdOptions(GetDepotDirsCmdFlags.SyncedDirs, null);
IList<String> dirs = new List<String>()
dirs.Add("//*");
IList<String> target = Repository.GetDepotDirs(dirs, opts);
</code>
To get dirs on the server that fall under the path //depot/main/:
<code>
GetDepotDirsCmdOptions opts =
new GetDepotDirsCmdOptions(GetDepotDirsCmdFlags.None, null);
IList<String> dirs = new List<String>()
dirs.Add("//depot/main/*");
IList<String> target = Repository.GetDepotDirs(dirs, opts);
</code>
</example>
<seealso cref="T:Perforce.P4.GetDepotDirsCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.GetFileContents(Perforce.P4.Options,Perforce.P4.FileSpec[])">
<summary>
Return the contents of the files identified by the passed-in file specs.
</summary>
<param name="filespecs"></param>
<param name="options"></param>
<returns></returns>
GetFileContents
<remarks>
<br/><b>p4 help print</b>
<br/>
<br/> print -- Write a depot file to standard output
<br/>
<br/> p4 print [-a -A -k -o localFile -q -m max] file[revRange] ...
<br/> p4 print -U unloadfile ...
<br/>
<br/> Retrieve the contents of a depot file to the client's standard output.
<br/> The file is not synced. If file is specified using client syntax,
<br/> Perforce uses the client view to determine the corresponding depot
<br/> file.
<br/>
<br/> By default, the head revision is printed. If the file argument
<br/> includes a revision, the specified revision is printed. If the
<br/> file argument has a revision range, then only files selected by
<br/> that revision range are printed, and the highest revision in the
<br/> range is printed. For details about revision specifiers, see 'p4
<br/> help revisions'.
<br/>
<br/> The -a flag prints all revisions within the specified range, rather
<br/> than just the highest revision in the range.
<br/>
<br/> The -A flag prints files in archive depots.
<br/>
<br/> The -k flag suppresses keyword expansion.
<br/>
<br/> The -o localFile flag redirects the output to the specified file on
<br/> the client filesystem.
<br/>
<br/> The -q flag suppresses the initial line that displays the file name
<br/> and revision.
<br/>
<br/> The -m flag limits print to the first 'max' number of files.
<br/>
<br/> The -U option prints files in the unload depot (see 'p4 help unload'
<br/> for more information about the unload depot).
<br/>
<br/>
</remarks>
<example>
To get the contents of the file //depot/MyCode/README.txt:
<code>
GetFileContentsCmdOptions opts =
new GetFileContentsCmdOptions(GetFileContentsCmdFlags.None, null);
FileSpec filespec =
new FileSpec(new DepotPath("//depot/MyCode/README.txt"), null);
IList<String> target = Repository.GetFileContents(opts, filespec);
</code>
To get the contents of the file //depot/MyCode/README.txt redirecting the
contents to local file C:\Doc\README.txt and supressing the file name
and revision line:
<code>
GetFileContentsCmdOptions opts =
new GetFileContentsCmdOptions(GetFileContentsCmdFlags.Suppress,
"C:\\Doc\\README.txt");
FileSpec filespec =
new FileSpec(new DepotPath("//depot/MyCode/README.txt"), null);
IList<String> target = Repository.GetFileContents(opts, filespec);
</code>
</example>
<seealso cref="T:Perforce.P4.GetFileContentsCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.GetFileContents(System.Collections.Generic.IList{Perforce.P4.FileSpec},Perforce.P4.Options)">
<summary>
Return the contents of the files identified by the passed-in file specs.
</summary>
<param name="filespecs"></param>
<param name="options"></param>
<returns></returns>
GetFileContents
<remarks>
<br/><b>p4 help print</b>
<br/>
<br/> print -- Write a depot file to standard output
<br/>
<br/> p4 print [-a -A -k -o localFile -q -m max] file[revRange] ...
<br/> p4 print -U unloadfile ...
<br/>
<br/> Retrieve the contents of a depot file to the client's standard output.
<br/> The file is not synced. If file is specified using client syntax,
<br/> Perforce uses the client view to determine the corresponding depot
<br/> file.
<br/>
<br/> By default, the head revision is printed. If the file argument
<br/> includes a revision, the specified revision is printed. If the
<br/> file argument has a revision range, then only files selected by
<br/> that revision range are printed, and the highest revision in the
<br/> range is printed. For details about revision specifiers, see 'p4
<br/> help revisions'.
<br/>
<br/> The -a flag prints all revisions within the specified range, rather
<br/> than just the highest revision in the range.
<br/>
<br/> The -A flag prints files in archive depots.
<br/>
<br/> The -k flag suppresses keyword expansion.
<br/>
<br/> The -o localFile flag redirects the output to the specified file on
<br/> the client filesystem.
<br/>
<br/> The -q flag suppresses the initial line that displays the file name
<br/> and revision.
<br/>
<br/> The -m flag limits print to the first 'max' number of files.
<br/>
<br/> The -U option prints files in the unload depot (see 'p4 help unload'
<br/> for more information about the unload depot).
<br/>
<br/>
</remarks>
<example>
To get the contents of the file //depot/MyCode/README.txt:
<code>
GetFileContentsCmdOptions opts =
new GetFileContentsCmdOptions(GetFileContentsCmdFlags.None, null);
FileSpec filespec =
new FileSpec(new DepotPath("//depot/MyCode/README.txt"), null);
IList<FileSpec> filespecs = new List<FileSpec>();
filespecs.Add(filespec);
IList<String> target = Repository.GetFileContents(filespecs, opts);
</code>
To get the contents of the file //depot/MyCode/README.txt redirecting the
contents to local file C:\Doc\README.txt and supressing the file name
and revision line:
<code>
GetFileContentsCmdOptions opts =
new GetFileContentsCmdOptions(GetFileContentsCmdFlags.Suppress,
"C:\\Doc\\README.txt");
FileSpec filespec =
new FileSpec(new DepotPath("//depot/MyCode/README.txt"), null);
IList<FileSpec> filespecs = new List<FileSpec>();
filespecs.Add(filespec);
IList<String> target = Repository.GetFileContents(filespecs, opts);
</code>
</example>
<seealso cref="T:Perforce.P4.GetFileContentsCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.GetFileContentsEx(Perforce.P4.Options,Perforce.P4.FileSpec[])">
<summary>
Return the contents of the files identified by the passed-in file specs.
</summary>
<param name="filespecs"></param>
<param name="options"></param>
<returns></returns>
GetFileContentsEx
<remarks>
<br/><b>p4 help print</b>
<br/>
<br/> print -- Write a depot file to standard output
<br/>
<br/> p4 print [-a -A -k -o localFile -q -m max] file[revRange] ...
<br/> p4 print -U unloadfile ...
<br/>
<br/> Retrieve the contents of a depot file to the client's standard output.
<br/> The file is not synced. If file is specified using client syntax,
<br/> Perforce uses the client view to determine the corresponding depot
<br/> file.
<br/>
<br/> By default, the head revision is printed. If the file argument
<br/> includes a revision, the specified revision is printed. If the
<br/> file argument has a revision range, then only files selected by
<br/> that revision range are printed, and the highest revision in the
<br/> range is printed. For details about revision specifiers, see 'p4
<br/> help revisions'.
<br/>
<br/> The -a flag prints all revisions within the specified range, rather
<br/> than just the highest revision in the range.
<br/>
<br/> The -A flag prints files in archive depots.
<br/>
<br/> The -k flag suppresses keyword expansion.
<br/>
<br/> The -o localFile flag redirects the output to the specified file on
<br/> the client filesystem.
<br/>
<br/> The -q flag suppresses the initial line that displays the file name
<br/> and revision.
<br/>
<br/> The -m flag limits print to the first 'max' number of files.
<br/>
<br/> The -U option prints files in the unload depot (see 'p4 help unload'
<br/> for more information about the unload depot).
<br/>
<br/>
</remarks>
<example>
To get the contents of the file //depot/MyCode/README.txt:
<code>
GetFileContentsCmdOptions opts =
new GetFileContentsCmdOptions(GetFileContentsCmdFlags.None, null);
FileSpec filespec =
new FileSpec(new DepotPath("//depot/MyCode/README.txt"), null);
IList<String> target = Repository.GetFileContents(opts, filespec);
</code>
To get the contents of the file //depot/MyCode/README.txt redirecting the
contents to local file C:\Doc\README.txt and supressing the file name
and revision line:
<code>
GetFileContentsCmdOptions opts =
new GetFileContentsCmdOptions(GetFileContentsCmdFlags.Suppress,
"C:\\Doc\\README.txt");
FileSpec filespec =
new FileSpec(new DepotPath("//depot/MyCode/README.txt"), null);
IList<String> target = Repository.GetFileContents(opts, filespec);
</code>
</example>
<seealso cref="T:Perforce.P4.GetFileContentsCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.GetFileContentsEx(System.Collections.Generic.IList{Perforce.P4.FileSpec},Perforce.P4.Options)">
<summary>
Return the contents of the files identified by the passed-in file specs.
</summary>
<param name="filespecs"></param>
<param name="options"></param>
<returns></returns>
GetFileContentsEx
<remarks>
<br/><b>p4 help print</b>
<br/>
<br/> print -- Write a depot file to standard output
<br/>
<br/> p4 print [-a -A -k -o localFile -q -m max] file[revRange] ...
<br/> p4 print -U unloadfile ...
<br/>
<br/> Retrieve the contents of a depot file to the client's standard output.
<br/> The file is not synced. If file is specified using client syntax,
<br/> Perforce uses the client view to determine the corresponding depot
<br/> file.
<br/>
<br/> By default, the head revision is printed. If the file argument
<br/> includes a revision, the specified revision is printed. If the
<br/> file argument has a revision range, then only files selected by
<br/> that revision range are printed, and the highest revision in the
<br/> range is printed. For details about revision specifiers, see 'p4
<br/> help revisions'.
<br/>
<br/> The -a flag prints all revisions within the specified range, rather
<br/> than just the highest revision in the range.
<br/>
<br/> The -A flag prints files in archive depots.
<br/>
<br/> The -k flag suppresses keyword expansion.
<br/>
<br/> The -o localFile flag redirects the output to the specified file on
<br/> the client filesystem.
<br/>
<br/> The -q flag suppresses the initial line that displays the file name
<br/> and revision.
<br/>
<br/> The -m flag limits print to the first 'max' number of files.
<br/>
<br/> The -U option prints files in the unload depot (see 'p4 help unload'
<br/> for more information about the unload depot).
<br/>
<br/>
</remarks>
<example>
To get the contents of the file //depot/MyCode/README.txt:
<code>
GetFileContentsCmdOptions opts =
new GetFileContentsCmdOptions(GetFileContentsCmdFlags.None, null);
FileSpec filespec =
new FileSpec(new DepotPath("//depot/MyCode/README.txt"), null);
IList<FileSpec> filespecs = new List<FileSpec>();
filespecs.Add(filespec);
IList<String> target = Repository.GetFileContents(filespecs, opts);
</code>
To get the contents of the file //depot/MyCode/README.txt redirecting the
contents to local file C:\Doc\README.txt and supressing the file name
and revision line:
<code>
GetFileContentsCmdOptions opts =
new GetFileContentsCmdOptions(GetFileContentsCmdFlags.Suppress,
"C:\\Doc\\README.txt");
FileSpec filespec =
new FileSpec(new DepotPath("//depot/MyCode/README.txt"), null);
IList<FileSpec> filespecs = new List<FileSpec>();
filespecs.Add(filespec);
IList<String> target = Repository.GetFileContents(filespecs, opts);
</code>
</example>
<seealso cref="T:Perforce.P4.GetFileContentsCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.GetFileHistory(Perforce.P4.Options,Perforce.P4.FileSpec[])">
<summary>
Get the revision history data for the passed-in file specs.
</summary>
<param name="filespecs"></param>
<param name="options"></param>
<returns></returns>
<remarks>
<br/><b>p4 help filelog</b>
<br/>
<br/> filelog -- List revision history of files
<br/>
<br/> p4 filelog [-c changelist# -h -i -l -L -t -m max -p -s] file[revRange] ...
<br/>
<br/> List the revision history of the specified files, from the most
<br/> recent revision to the first. If the file specification includes
<br/> a revision, the command lists revisions at or prior to the specified
<br/> revision. If the file specification includes a revision range,
<br/> the command lists only the specified revisions. See 'p4 help revisions'
<br/> for details.
<br/>
<br/> The -c changelist# flag displays files submitted at the specified
<br/> changelist number.
<br/>
<br/> The -i flag includes inherited file history. If a file was created by
<br/> branching (using 'p4 integrate'), filelog lists the revisions of the
<br/> file's ancestors up to the branch points that led to the specified
<br/> revision. File history inherited by renaming (using 'p4 move') is
<br/> always displayed regardless of whether -i is specified.
<br/>
<br/> The -h flag displays file content history instead of file name
<br/> history. The list includes revisions of other files that were
<br/> branched or copied (using 'p4 integrate' and 'p4 resolve -at') to
<br/> the specified revision. Revisions that were replaced by copying
<br/> or branching are omitted, even if they are part of the history of
<br/> the specified revision.
<br/>
<br/> The -t flag displays the time as well as the date.
<br/>
<br/> The -l flag lists the full text of the changelist descriptions.
<br/>
<br/> The -L flag lists the full text of the changelist descriptions,
<br/> truncated to 250 characters if longer.
<br/>
<br/> The -m max displays at most 'max' revisions per file of the file[rev]
<br/> argument specified.
<br/>
<br/> The -p flag is used in conjunction with the '-h' flag to prevent
<br/> filelog from following content of promoted task streams. This flag
<br/> is useful when there are many child task streams branched from the
<br/> file argument supplied.
<br/>
<br/> The -s flag displays a shortened form of filelog that omits
<br/> non-contributory integrations.
<br/>
<br/>
</remarks>
<example>
To get the file history of the file //depot/MyCode/README.txt
submitted at change 43578 and showing the full changelist description:
<code>
GetFileHistoryCmdOptions opts =
new GetFileHistoryCmdOptions(GetFileHistoryCmdFlags.FullDescription
43578, 0);
FileSpec filespec =
new FileSpec(new DepotPath("//depot/MyCode/README.txt"), null);
IList<String> target = Repository.GetFileHistory(opts, filespec);
</code>
To get the file history of the file //depot/MyCode/README.txt
showing both time and date for the 10 latest revisions:
<code>
GetFileHistoryCmdOptions opts =
new GetFileHistoryCmdOptions(GetFileHistoryCmdFlags.Time,
0, 10)
FileSpec filespec =
new FileSpec(new DepotPath("//depot/MyCode/README.txt"), null);
IList<String> target = Repository.GetFileHistory(opts, filespec);
</code>
</example>
<seealso cref="T:Perforce.P4.FileLogCmdFlags"/>
<seealso cref="T:Perforce.P4.GetFileHistoryCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.GetFileHistory(System.Collections.Generic.IList{Perforce.P4.FileSpec},Perforce.P4.Options)">
<summary>
Get the revision history data for the passed-in file specs.
</summary>
<param name="filespecs"></param>
<param name="options"></param>
<returns></returns>
<remarks>
<br/><b>p4 help filelog</b>
<br/>
<br/> filelog -- List revision history of files
<br/>
<br/> p4 filelog [-c changelist# -h -i -l -L -t -m max -p -s] file[revRange] ...
<br/>
<br/> List the revision history of the specified files, from the most
<br/> recent revision to the first. If the file specification includes
<br/> a revision, the command lists revisions at or prior to the specified
<br/> revision. If the file specification includes a revision range,
<br/> the command lists only the specified revisions. See 'p4 help revisions'
<br/> for details.
<br/>
<br/> The -c changelist# flag displays files submitted at the specified
<br/> changelist number.
<br/>
<br/> The -i flag includes inherited file history. If a file was created by
<br/> branching (using 'p4 integrate'), filelog lists the revisions of the
<br/> file's ancestors up to the branch points that led to the specified
<br/> revision. File history inherited by renaming (using 'p4 move') is
<br/> always displayed regardless of whether -i is specified.
<br/>
<br/> The -h flag displays file content history instead of file name
<br/> history. The list includes revisions of other files that were
<br/> branched or copied (using 'p4 integrate' and 'p4 resolve -at') to
<br/> the specified revision. Revisions that were replaced by copying
<br/> or branching are omitted, even if they are part of the history of
<br/> the specified revision.
<br/>
<br/> The -t flag displays the time as well as the date.
<br/>
<br/> The -l flag lists the full text of the changelist descriptions.
<br/>
<br/> The -L flag lists the full text of the changelist descriptions,
<br/> truncated to 250 characters if longer.
<br/>
<br/> The -m max displays at most 'max' revisions per file of the file[rev]
<br/> argument specified.
<br/>
<br/> The -p flag is used in conjunction with the '-h' flag to prevent
<br/> filelog from following content of promoted task streams. This flag
<br/> is useful when there are many child task streams branched from the
<br/> file argument supplied.
<br/>
<br/> The -s flag displays a shortened form of filelog that omits
<br/> non-contributory integrations.
<br/>
<br/>
</remarks>
<example>
To get the file history of the file //depot/MyCode/README.txt
submitted at change 43578 and showing the full changelist description:
<code>
GetFileHistoryCmdOptions opts =
new GetFileHistoryCmdOptions(GetFileHistoryCmdFlags.FullDescription
43578, 0);
FileSpec filespec =
new FileSpec(new DepotPath("//depot/MyCode/README.txt"), null);
IList<FileSpec> filespecs = new List<FileSpec>();
filespecs.Add(filespec);
IList<String> target = Repository.GetFileHistory(filespecs, opts);
</code>
To get the file history of the file //depot/MyCode/README.txt
showing both time and date for the 10 latest revisions:
<code>
GetFileHistoryCmdOptions opts =
new GetFileHistoryCmdOptions(GetFileHistoryCmdFlags.Time,
0, 10)
FileSpec filespec =
new FileSpec(new DepotPath("//depot/MyCode/README.txt"), null);
IList<FileSpec> filespecs = new List<FileSpec>();
filespecs.Add(filespec);
IList<String> target = Repository.GetFileHistory(filespecs, opts);
</code>
</example>
<seealso cref="T:Perforce.P4.FileLogCmdFlags"/>
<seealso cref="T:Perforce.P4.GetFileHistoryCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.GetDepotFileDiffs(System.String,System.String,Perforce.P4.Options)">
<summary>
Get content and existence diff details for two depot files.
</summary>
<param name="filespecleft"></param>
<param name="filespecright"></param>
<param name="options"></param>
<returns></returns>
<remarks>
<br/><b>p4 help diff2</b>
<br/>
<br/> diff2 -- Compare one set of depot files to another
<br/>
<br/> p4 diff2 [options] fromFile[rev] toFile[rev]
<br/> p4 diff2 [options] -b branch [[fromFile[rev]] toFile[rev]]
<br/> p4 diff2 [options] -S stream [-P parent] [[fromFile[rev]] toFile[rev]]
<br/>
<br/> options: -d<flags> -Od -q -t -u
<br/>
<br/> 'p4 diff2' runs on the server to compare one set of depot files (the
<br/> 'source') to another (the 'target'). Source and target file sets
<br/> can be specified on the 'p4 diff2' command line or through a branch
<br/> view.
<br/>
<br/> With a branch view, fromFile and toFile are optional; fromFile limits
<br/> the scope of the source file set, and toFile limits the scope of the
<br/> target. If only one file argument is given, it is assumed to be
<br/> toFile.
<br/>
<br/> fromFile and toFile can include revision specifiers; by default, the
<br/> head revisions are diffed. See 'p4 help revisions' for details
<br/> about specifying file revisions.
<br/>
<br/> 'p4 diff2' precedes each diffed file pair with a header line of the
<br/> following form:
<br/>
<br/> ==== source#rev (type) - target#rev (type) ==== summary
<br/>
<br/> A source or target file shown as '<none>' means there is no file
<br/> at the specified name or revision to pair with its counterpart.
<br/> The summary status is one of the following: 'identical' means file
<br/> contents and types are identical, 'types' means file contents are
<br/> identical but the types are different, and 'content' means file
<br/> contents are different.
<br/>
<br/> The -b flag makes 'p4 diff2' use a user-defined branch view. (See
<br/> 'p4 help branch'.) The left side of the branch view is the source
<br/> and the right side is the target.
<br/>
<br/> The -S flag makes 'p4 diff2' use a generated branch view that maps
<br/> a stream (or its underlying real stream) to its parent. -P can be
<br/> used to generate the branch view using a parent stream other than
<br/> the stream's actual parent.
<br/>
<br/> The -d<flags> modify the output of diffs as follows:
<br/>
<br/> -dn (RCS)
<br/> -dc[n] (context)
<br/> -ds (summary)
<br/> -du[n] (unified)
<br/> -db (ignore whitespace changes)
<br/> -dw (ignore whitespace)
<br/> -dl (ignore line endings).
<br/>
<br/> The optional argument to -dc/-du specifies number of context lines.
<br/>
<br/> The -Od flag limits output to files that differ.
<br/>
<br/> The -q omits files that have identical content and types and
<br/> suppresses the actual diff for all files.
<br/>
<br/> The -t flag forces 'p4 diff2' to diff binary files.
<br/>
<br/> The -u flag uses the GNU diff -u format and displays only files
<br/> that differ. The file names and dates are in Perforce syntax, but
<br/> the output can be used by the patch program.
<br/>
<br/>
</remarks>
<example>
To get the depot file diffs between //depot/main/Program.cs and
//depot/rel/Program.cs and ignore whitespace changes:
<code>
GetDepotFileDiffsCmdOptions opts =
new GetDepotFileDiffsCmdOptions(GetDepotFileDiffsCmdFlags.IgnoreWhitespaceChanges,
0, 0, null,null,null);
IList<DepotFileDiff> target =
Repository.GetDepotFileDiffs(//depot/main/Program.cs,
//depot/rel/Program.cs, opts);
</code>
To get the depot files that differ between all files under //depot/main/... and
//depot/rel/... and display in GNU format only listing files that differ:
<code>
GetDepotFileDiffsCmdOptions opts =
new GetDepotFileDiffsCmdOptions(GetDepotFileDiffsCmdFlags.GNU,
0, 0, null,null,null);
IList<DepotFileDiff> target =
Repository.GetDepotFileDiffs(//depot/main/..., //depot/rel/..., opts);
</code>
</example>
<seealso cref="T:Perforce.P4.GetDepotFileDiffsCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.GetFileAnnotations(System.Collections.Generic.IList{Perforce.P4.FileSpec},Perforce.P4.Options)">
<summary>
Return FileAnnotation objects for the listed FileSpecs.
</summary>
<param name="filespecs"></param>
<param name="options"></param>
<returns></returns>
<remarks>
<br/><b>p4 help annotate</b>
<br/>
<br/> annotate -- Print file lines and their revisions
<br/>
<br/> p4 annotate [-aciIqt -d<flags>] file[revRange] ...
<br/>
<br/> Prints all lines of the specified files, indicating the revision that
<br/> introduced each line into the file.
<br/>
<br/> If the file argument includes a revision, then only revisions up to
<br/> the specified revision are displayed. If the file argument has a
<br/> revision range, only revisions within that range are displayed. For
<br/> details about specifying revisions, see 'p4 help revisions'.
<br/>
<br/> The -a flag includes both deleted files and lines no longer present
<br/> at the head revision. In the latter case, both the starting and ending
<br/> revision for each line is displayed.
<br/>
<br/> The -c flag directs the annotate command to output changelist numbers
<br/> rather than revision numbers for each line.
<br/>
<br/> The -d<flags> change the way whitespace and/or line endings are
<br/> treated: -db (ignore whitespace changes), -dw (ignore whitespace),
<br/> -dl (ignore line endings).
<br/>
<br/> The -i flag follows branches. If a file was created by branching,
<br/> 'p4 annotate' includes the revisions of the source file up to the
<br/> branch point, just as 'p4 filelog -i' does. If a file has history
<br/> prior to being created by branching (such as a file that was branched
<br/> on top of a deleted file), -i ignores those prior revisions and
<br/> follows the source. -i implies -c.
<br/>
<br/> The -I flag follows all integrations into the file. If a line was
<br/> introduced into the file by a merge, the source of the merge is
<br/> displayed as the changelist that introduced the line. If the source
<br/> itself was the result of an integration, that source is used instead,
<br/> and so on. -I implies -c and may not be combined with -i.
<br/>
<br/> The -q flag suppresses the one-line header that is displayed by
<br/> default for each file.
<br/>
<br/> The -t flag forces 'p4 annotate' to display binary files.
<br/>
<br/>
</remarks>
<example>
To get the file annotations of the file //depot/MyCode/README.txt:
<code>
GetFileAnnotationsCmdOptions opts =
new GetFileAnnotationsCmdOptions(GetFileAnnotationsCmdFlags.None, null);
FileSpec filespec =
new FileSpec(new DepotPath("//depot/MyCode/README.txt"), null);
IList<FileSpec> filespecs = new List<FileSpec>();
filespecs.Add(filespec);
IList<FileAnnotation> target = Repository.GetFileAnnotations(filespecs, opts);
</code>
To get the file annotations of the file //depot/MyCode/README.txt redirecting the
contents to local file C:\Doc\README.txt and supressing the one-line header:
<code>
GetFileAnnotationsCmdOptions opts =
new GetFileAnnotationsCmdOptions(GetFileAnnotationsCmdFlags.Suppress,
"C:\\Doc\\README.txt");
FileSpec filespec =
new FileSpec(new DepotPath("//depot/MyCode/README.txt"), null);
IList<FileSpec> filespecs = new List<FileSpec>();
filespecs.Add(filespec);
IList<FileAnnotation> target = Repository.GetFileAnnotations(filespecs, opts);
</code>
</example>
<seealso cref="T:Perforce.P4.GetFileAnnotationsCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.TagFiles(System.Collections.Generic.IList{Perforce.P4.FileSpec},System.String,Perforce.P4.Options)">
<summary>
Tag depot files with the passed-in label.
</summary>
<param name="filespecs"></param>
<param name="labelid"></param>
<param name="options"></param>
<returns></returns>
<remarks>
<br/><b>p4 help tag</b>
<br/>
<br/> tag -- Tag files with a label
<br/>
<br/> p4 tag [-d -g -n -U] -l label file[revRange] ...
<br/>
<br/> Tag associates the named label with the file revisions specified by
<br/> the file argument. After file revisions are tagged with a label,
<br/> revision specifications of the form '@label' can be used to refer
<br/> to them.
<br/>
<br/> If the file argument does not include a revision specification, the
<br/> head revisions is tagged. See 'p4 help revisions' for revision
<br/> specification options.
<br/>
<br/> If the file argument includes a revision range specification, only
<br/> the files with revisions in that range are tagged. Files with more
<br/> than one revision in the range are tagged at the highest revision.
<br/>
<br/> The -d deletes the association between the specified files and the
<br/> label, regardless of revision.
<br/>
<br/> The -n flag previews the results of the operation.
<br/>
<br/> Tag can be used with an existing label (see 'p4 help labels') or
<br/> with a new one. An existing label can be used only by its owner,
<br/> and only if it is unlocked. (See 'p4 help label').
<br/>
<br/> The -U flag specifies that the new label should be created with the
<br/> 'autoreload' option (See 'p4 help label'). It has no effect on an
<br/> existing label.
<br/>
<br/> To list the file revisions tagged with a label, use 'p4 files
<br/> @label'.
<br/>
<br/> The -g flag is used on an Edge Server to update a global label.
<br/> Configuring rpl.labels.global=1 reverses this default and causes this
<br/> flag to have the opposite meaning.
<br/>
<br/>
</remarks>
<example>
To tag the file //depot/MyCode/README.txt with build_label:
<code>
TagCmdOptions opts =
new TagCmdOptions(TagFilesCmdFlags.None, null);
FileSpec filespec =
new FileSpec(new DepotPath("//depot/MyCode/README.txt"), null);
IList<FileSpec> filespecs = new List<FileSpec>();
filespecs.Add(filespec);
IList<FileSpec> target =
Repository.TagFiles(filespecs, "build_label", opts);
</code>
To remove the association between the file //depot/MyCode/README.txt
and build_label:
<code>
TagCmdOptions opts =
new TagCmdOptions(TagFilesCmdFlags.Delete, null);
FileSpec filespec =
new FileSpec(new DepotPath("//depot/MyCode/README.txt"), null);
IList<FileSpec> filespecs = new List<FileSpec>();
filespecs.Add(filespec);
IList<FileSpec> target =
Repository.TagFiles(filespecs, "build_label", opts);
</code>
To get a preview list of the files that would be tagged in path
//depot/main/src with build_label:
<code>
TagCmdOptions opts =
new TagCmdOptions(TagFilesCmdFlags.ListOnly, null);
FileSpec filespec =
new FileSpec(new DepotPath("//depot/main/src/..."), null);
IList<FileSpec> filespecs = new List<FileSpec>();
filespecs.Add(filespec);
IList<FileSpec> target =
Repository.TagFiles(filespecs, "build_label", opts);
</code>
</example>
<seealso cref="T:Perforce.P4.TagFilesCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.GetFixes(System.Collections.Generic.IList{Perforce.P4.FileSpec},Perforce.P4.Options)">
<summary>
List fixes affecting files and / or jobs and / or changelists.
</summary>
<param name="filespecs"></param>
<param name="options"></param>
<returns></returns>
<remarks>
<br/><b>p4 help fixes</b>
<br/>
<br/> fixes -- List jobs with fixes and the changelists that fix them
<br/>
<br/> p4 fixes [-i -m max -c changelist# -j jobName] [file[revRange] ...]
<br/>
<br/> 'p4 fixes' list fixed jobs and the number of the changelist that
<br/> contains the fix. Fixes are associated with changelists using the
<br/> 'p4 fix' command or by editing and submitting changelists.
<br/>
<br/> The 'p4 fixes' command lists both submitted and pending changelists.
<br/>
<br/> By default, 'p4 fixes' lists all fixes. This list can be limited
<br/> as follows: to list fixes for a specified job, use the -j jobName
<br/> flag. To list fixes for a specified changelist, use -c changelist#.
<br/> To list fixes that affect specified files, include the file argument.
<br/> The file pattern can include wildcards and revision specifiers. For
<br/> details about revision specifiers, see 'p4 help revisions'
<br/>
<br/> The -i flag also includes any fixes made by changelists integrated
<br/> into the specified files.
<br/>
<br/> The -m max flag limits output to the specified number of job
<br/> fixes.
<br/>
<br/>
</remarks>
<example>
To list the fixes related to job000001:
<code>
GetFixesCmdOptions opts =
new GetFixesCmdOptions(GetFixesCmdFlags.None, 0, "job000001", 0);
FileSpec filespec =
new FileSpec(new DepotPath("//..."), null);
IList<FileSpec> filespecs = new List<FileSpec>();
filespecs.Add(filespec);
IList<Fix> target = Repository.GetFixes(filespecs, opts);
</code>
To list the fixes related to changelist 47921:
<code>
GetFixesCmdOptions opts =
new GetFixesCmdOptions(GetFixesCmdFlags.None, 47921, null, 0);
FileSpec filespec =
new FileSpec(new DepotPath("//..."), null);
IList<FileSpec> filespecs = new List<FileSpec>();
filespecs.Add(filespec);
IList<Fix> target = Repository.GetFixes(filespecs, opts);
</code>
To list the fixes related to path //depot/rel/src that occurred
between 2014/1/1 and 2014/1/31:
<code>
GetFixesCmdOptions opts =
new GetFixesCmdOptions(GetFixesCmdFlags.None, 0, null, 0);
VersionRange vr = new VersionRange(new DateTimeVersion(new DateTime(2014, 1, 1)),
new DateTimeVersion(new DateTime(2014, 1, 31)));
FileSpec filespec =
new FileSpec(new DepotPath("//..."), vr);
IList<FileSpec> filespecs = new List<FileSpec>();
filespecs.Add(filespec);
IList<Fix> target = Repository.GetFixes(filespecs, opts);
</code>
</example>
<seealso cref="T:Perforce.P4.GetFixesCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.GetFileLineMatches(System.Collections.Generic.IList{Perforce.P4.FileSpec},System.String,Perforce.P4.Options)">
<summary>
Get a list of matching lines in the passed-in file specs.
</summary>
<param name="filespecs"></param>
<param name="pattern"></param>
<param name="options"></param>
<returns></returns>
<remarks>
<br/><b>p4 help grep</b>
<br/>
<br/> grep -- Print lines matching a pattern
<br/>
<br/> p4 grep [options] -e pattern file[revRange]...
<br/>
<br/> options: -a -i -n -A <num> -B <num> -C <num> -t -s (-v|-l|-L) (-F|-G)
<br/>
<br/> Searches files for lines that match the specified regular expression,
<br/> which can contain wildcards. The parser used by the Perforce server
<br/> is based on V8 regexp and might not be compatible with later parsers,
<br/> but the majority of functionality is available.
<br/>
<br/> By default the head revision is searched. If the file argument includes
<br/> a revision specification, all corresponding revisions are searched.
<br/> If the file argument includes a revision range, only files in that
<br/> range are listed, and the highest revision in the range is searched.
<br/> For details about revision specifiers, see 'p4 help revisions'.
<br/>
<br/> The -a flag searches all revisions within the specified range. By
<br/> default only the highest revision in the range is searched.
<br/>
<br/> The -i flag causes the pattern matching to be case-insensitive. By
<br/> default, matching is case-sensitive.
<br/>
<br/> The -n flag displays the matching line number after the file revision
<br/> number. By default, matches are displayed as revision#: <text>.
<br/>
<br/> The -v flag displays files with non-matching lines.
<br/>
<br/> The -F flag is used to interpret the pattern as a fixed string.
<br/>
<br/> The -G flag is used to interpret the pattern as a regular expression,
<br/> which is the default behavior.
<br/>
<br/> The -L flag displays the name of each selected file from which no
<br/> output would normally have been displayed. Scanning stops on the
<br/> first match.
<br/>
<br/> The -l flag displays the name of each selected file containing
<br/> matching text. Scanning stops on the first match.
<br/>
<br/> The -s flag suppresses error messages that result from abandoning
<br/> files that have a maximum number of characters in a single line that
<br/> are greater than 4096. By default, an error is reported when grep
<br/> abandons such files.
<br/>
<br/> The -t flag searches binary files. By default, only text files are
<br/> searched.
<br/>
<br/> The -A <num> flag displays the specified number of lines of trailing
<br/> context after matching lines.
<br/>
<br/> The -B <num> flag displays the specified number of lines of leading
<br/> context before matching lines.
<br/>
<br/> The -C <num> flag displays the specified number of lines of output
<br/> context.
<br/>
<br/> Regular expressions:
<br/>
<br/> A regular expression is zero or more branches, separated by `|'. It
<br/> matches anything that matches one of the branches.
<br/>
<br/> A branch is zero or more pieces, concatenated. It matches a match
<br/> for the first, followed by a match for the second, etc.
<br/>
<br/> A piece is an atom possibly followed by `*', `+', or `?'. An atom
<br/> followed by `*' matches a sequence of 0 or more matches of the atom.
<br/> An atom followed by `+' matches a sequence of 1 or more matches of
<br/> the atom. An atom followed by `?' matches a match of the atom, or
<br/> the null string.
<br/>
<br/> An atom is a regular expression in parentheses (matching a match for
<br/> the regular expression), a range (see below), `.' (matching any
<br/> single character), `^' (matching the null string at the beginning
<br/> of the input string), `$' (matching the null string at the end of
<br/> the input string), a `\' followed by a single character (matching
<br/> that character), or a single character with no other significance
<br/> (matching that character).
<br/>
<br/> A range is a sequence of characters enclosed in `[]'. It normally
<br/> matches any single character from the sequence. If the sequence
<br/> begins with `^', it matches any single character not from the rest
<br/> of the sequence. If two characters in the sequence are separated by
<br/> `-', this is shorthand for the full list of ASCII characters between
<br/> them (e.g. `[0-9]' matches any decimal digit). To include a literal
<br/> `]' in the sequence, make it the first character (following a possible
<br/> `^'). To include a literal `-', make it the first or last character.
<br/>
<br/> The symbols '\<' and '\>' respectively match the empty string at
<br/> the beginning and end of a word.
<br/>
<br/>
</remarks>
<example>
To get the file line matches for the pattern "OpenConnection" in the
file //depot/main/Program.cs with case-insensitive search:
<code>
GetFileLineMatchesCmdOptions opts =
new GetFileLineMatchesCmdOptions(GetFileLineMatchesCmdFlags.CaseInsensitive,
0, 0, 0);
FileSpec filespec =
new FileSpec(new DepotPath("//depot/main/Program.cs"), null);
IList<FileSpec> filespecs = new List<FileSpec>();
filespecs.Add(filespec);
IList<FileLineMatch> target =
Repository.GetFileLineMatches(filespecs, "OpenConnection" opts);
</code>
To get the file line matches for the pattern "OpenConnection" in the
file //depot/main/Program.cs showing 2 lines before and after the found
pattern and showing line numbers:
<code>
GetFileLineMatchesCmdOptions opts =
new GetFileLineMatchesCmdOptions(GetFileLineMatchesCmdFlags.IncludeLineNumbers,
2, 2, 0);
FileSpec filespec =
new FileSpec(new DepotPath("//depot/main/Program.cs"), null);
IList<FileSpec> filespecs = new List<FileSpec>();
filespecs.Add(filespec);
IList<FileLineMatch> target =
Repository.GetFileLineMatches(filespecs, "OpenConnection" opts);
</code>
</example>
<seealso cref="T:Perforce.P4.GetFileLineMatchesCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.GetSubmittedIntegrations(System.Collections.Generic.IList{Perforce.P4.FileSpec},Perforce.P4.Options)">
<summary>
Get a list of submitted integrations for the passed-in file specs.
</summary>
<param name="filespecs"></param>
<param name="options"></param>
<returns></returns>
<remarks>
<br/><b>p4 help integrated</b>
<br/>
<br/> integrated -- List integrations that have been submitted
<br/>
<br/> p4 integrated [-r] [-b branch] [file ...]
<br/>
<br/> The p4 integrated command lists integrations that have been submitted.
<br/> To list unresolved integrations, use 'p4 resolve -n'. To list
<br/> resolved but unsubmitted integrations, use 'p4 resolved'.
<br/>
<br/> If the -b branch flag is specified, only files integrated from the
<br/> source to target files in the branch view are listed. Qualified
<br/> files are listed, even if they were integrated without using the
<br/> branch view.
<br/>
<br/> The -r flag reverses the mappings in the branch view, swapping the
<br/> target files and source files. The -b branch flag is required.
<br/>
<br/>
</remarks>
<example>
To get the file intergration records for the path //depot/rel defined
by branch specification main_to_rel:
<code>
GetSubmittedIntegrationsCmdOptions opts =
new GetSubmittedIntegrationsCmdOptions(GetSubmittedIntegrationsCmdFlags.None,
"main_to_rel");
FileSpec filespec =
new FileSpec(new DepotPath("//depot/rel/..."), null);
IList<FileSpec> filespecs = new List<FileSpec>();
filespecs.Add(filespec);
IList<FileIntegrationRecord> target =
Repository.GetSubmittedIntegrations(filespecs, opts);
</code>
To get the file intergration records for the path //depot/main defined
by branch specification main_to_rel in reverse direction:
<code>
GetSubmittedIntegrationsCmdOptions opts =
new GetSubmittedIntegrationsCmdOptions(GetSubmittedIntegrationsCmdFlags.ReverseMappings,
"main_to_rel");
FileSpec filespec =
new FileSpec(new DepotPath("//depot/rel/..."), null);
IList<FileSpec> filespecs = new List<FileSpec>();
filespecs.Add(filespec);
IList<FileIntegrationRecord> target =
Repository.GetSubmittedIntegrations(filespecs, opts);
</code>
</example>
<seealso cref="T:Perforce.P4.GetSubmittedIntegrationsCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.GetProtectionEntries(System.Collections.Generic.IList{Perforce.P4.FileSpec},Perforce.P4.Options)">
<summary>
Get a list of Perforce protection entries for the passed-in file specs
</summary>
<param name="filespecs"></param>
<param name="options"></param>
<returns></returns>
<remarks>
<br/><b>p4 help protects</b>
<br/>
<br/> protects -- Display protections defined for a specified user and path
<br/>
<br/> p4 protects [-a | -g group | -u user] [-h host] [-m] [file ...]
<br/>
<br/> 'p4 protects' displays the lines from the protections table that
<br/> apply to the current user. The protections table is managed using
<br/> the 'p4 protect' command.
<br/>
<br/> If the -a flag is specified, protection lines for all users are
<br/> displayed. If the -g group flag or -u user flag is specified,
<br/> protection lines for that group or user are displayed.
<br/>
<br/> If the -h host flag is specified, the protection lines that apply
<br/> to the specified host (IP address) are displayed.
<br/>
<br/> If the -m flag is given, a single word summary of the maximum
<br/> access level is reported. Note that this summary does not take
<br/> exclusions or the specified file path into account.
<br/>
<br/> If the file argument is specified, protection lines that apply to
<br/> the specified files are displayed.
<br/>
<br/> The -a/-g/-u flags require 'super' access granted by 'p4 protect'.
<br/>
<br/>
</remarks>
<example>
To get the protections for the user tim for the entire server:
<code>
GetProtectionEntriesCmdOptions opts =
new GetProtectionEntriesCmdOptions(GetProtectionEntriesCmdFlags.None,
null, "tim", null);
FileSpec filespec =
new FileSpec(new DepotPath("//..."), null);
IList<FileSpec> filespecs = new List<FileSpec>();
filespecs.Add(filespec);
IList<ProtectionEntry> target =
Repository.GetProtectionEntries(filespecs, opts);
</code>
To get the protections summary for the group development tim for the entire server
when connecting from IP address 10.24.4.6:
<code>
GetProtectionEntriesCmdOptions opts =
new GetProtectionEntriesCmdOptions(GetProtectionEntriesCmdFlags.AccessSummary,
"development", null, "10.24.4.6");
FileSpec filespec =
new FileSpec(new DepotPath("//..."), null);
IList<FileSpec> filespecs = new List<FileSpec>();
filespecs.Add(filespec);
IList<ProtectionEntry> target =
Repository.GetProtectionEntries(filespecs, opts);
</code>
</example>
<seealso cref="T:Perforce.P4.GetProtectionEntriesCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.GetReviewers(System.Collections.Generic.IList{Perforce.P4.FileSpec},Perforce.P4.Options)">
<summary>
List Perforce users assigned to review files.
</summary>
<param name="filespecs"></param>
<param name="options"></param>
<returns></returns>
<remarks>
<br/><b>p4 help reviews</b>
<br/>
<br/> reviews -- List the users who are subscribed to review files
<br/>
<br/> p4 reviews [-C client] [-c changelist#] [file ...]
<br/>
<br/> 'p4 reviews' lists all users who have subscribed to review the
<br/> specified files.
<br/>
<br/> The -c flag limits the files to the submitted changelist.
<br/>
<br/> The -C flag limits the files to those opened in the specified clients
<br/> workspace, when used with the -c flag limits the workspace to files
<br/> opened in the specified changelist.
<br/>
<br/> To subscribe to review files, issue the 'p4 user' command and edit
<br/> the 'Reviews field'.
<br/>
<br/>
</remarks>
<example>
To get the list of users who are reviewing submits to //depot/main/src:
<code>
GetReviewersCmdOptions opts =
new GetReviewersCmdOptions(GetReviewersCmdFlags.None, 0);
FileSpec filespec =
new FileSpec(new DepotPath("//depot/main/src/..."), null);
IList<FileSpec> filespecs = new List<FileSpec>();
filespecs.Add(filespec);
IList<ProtectionEntry> target =
Repository.GetProtectionEntries(filespecs, opts);
</code>
To get the list of users who are reviewing submitted changelist 83476:
<code>
GetReviewersCmdOptions opts =
new GetReviewersCmdOptions(GetReviewersCmdFlags.None, 83476);
FileSpec filespec =
new FileSpec(new DepotPath("//..."), null);
IList<FileSpec> filespecs = new List<FileSpec>();
filespecs.Add(filespec);
IList<ProtectionEntry> target =
Repository.GetProtectionEntries(filespecs, opts);
</code>
</example>
<seealso cref="T:Perforce.P4.GetProtectionEntriesCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.GetFormSpec(Perforce.P4.Options,System.String)">
<summary>
Get a FormSpec of the specified form type.
</summary>
<param name="spectype"></param>
<param name="options"></param>
<returns></returns>
<remarks>
<br/><b>p4 help spec</b>
<br/>
<br/> spec -- Edit spec comments and formatting hints (unsupported)
<br/>
<br/> p4 spec [-d -i -o] type
<br/>
<br/> Edit any type of specification: branch, change, client, depot,
<br/> group, job, label, spec, stream, triggers, typemap, or user. Only
<br/> the comments and the formatting hints can be changed. Any fields
<br/> that you add during editing are discarded when the spec is saved.
<br/>
<br/> 'p4 jobspec' is equivalent to 'p4 spec job', and any custom spec
<br/> (including the job spec) can be deleted with 'p4 spec -d type'.
<br/>
<br/>
</remarks>
<example>
To get the FormSpec for changelist:
<code>
Options ops = new Options();
ops["-o"] = null;
FormSpec target = Repository.GetFormSpec(ops, "change");
</code>
To get the FormSpec for client:
<code>
Options ops = new Options();
ops["-o"] = null;
FormSpec target = Repository.GetFormSpec(ops, "clinet");
</code>
To get the FormSpec for user:
<code>
Options ops = new Options();
ops["-o"] = null;
FormSpec target = Repository.GetFormSpec(ops, "user");
</code>
</example>
</member>
<member name="M:Perforce.P4.Repository.GetTriggerTable(Perforce.P4.Options)">
<summary>
Get the repository's trigger table.
</summary>
<param name="options"></param>
<returns></returns>
<remarks>
<br/><b>p4 help triggers</b>
<br/>
<br/> triggers -- Modify list of server triggers
<br/>
<br/> p4 triggers
<br/> p4 triggers -o
<br/> p4 triggers -i
<br/>
<br/> 'p4 triggers' edits the table of triggers, which are used for
<br/> change submission validation, form validation, external authentication,
<br/> external job fix integration, external archive integration, and command
<br/> policies.
<br/>
<br/> Triggers are administrator-defined commands that the server runs
<br/> to perform the following:
<br/>
<br/> Validate changelist submissions.
<br/>
<br/> The server runs changelist triggers before the file transfer,
<br/> between file transfer and changelist commit, upon commit failure,
<br/> or after the commit.
<br/>
<br/> Validate shelve operations.
<br/>
<br/> The server runs shelve triggers before files are shelved, after
<br/> files are shelved, or when shelved files have been discarded
<br/> (via shelve -d).
<br/>
<br/> Manipulate and validate forms.
<br/>
<br/> The server runs form-validating triggers between generating
<br/> and outputting the form, between inputting and parsing the
<br/> form, between parsing and saving the form, or when deleting
<br/> the form.
<br/>
<br/> Authenticate or change a user password.
<br/>
<br/> The server runs authentication triggers to either validate
<br/> a user password during login or when setting a new password.
<br/>
<br/> Intercept job fix additions or deletions.
<br/>
<br/> The server run fix triggers prior to adding or deleting a fix
<br/> between a job and changelist.
<br/>
<br/> Access external archive files.
<br/>
<br/> For files with the +X filetype modifier, the server runs an
<br/> archive trigger to read, write, or delete files in the archive.
<br/>
<br/> Command execution policy.
<br/>
<br/> Command triggers can be specified to run before and after
<br/> processing of user requests. Pre-execution triggers can
<br/> prevent the command from running.
<br/>
<br/> The trigger form has a single entry 'Triggers:', followed by any
<br/> number of trigger lines. Each trigger line must be indented with
<br/> spaces or tabs in the form. Triggers are executed in the order listed
<br/> and if a trigger fails, subsequent triggers are not run. A trigger
<br/> succeeds if the executed command exits returning 0 and fails otherwise.
<br/> Normally the failure of a trigger prevents the operation from
<br/> completing, except for the commit triggers, which run after the
<br/> operation is complete, or the change-failed trigger which is only
<br/> advisory.
<br/>
<br/> Each trigger line contains a trigger name, a trigger type, a depot
<br/> file path pattern matching where the trigger will be executed, a
<br/> command name or form type and a command to run.
<br/>
<br/> Name: The name of the trigger. For change triggers, a run of the
<br/> same trigger name on contiguous lines is treated as a single
<br/> trigger so that multiple paths can be specified. Only the
<br/> command of the first such trigger line is used.
<br/>
<br/> Type: When the trigger is to execute:
<br/>
<br/> archive:
<br/> Execute an archive trigger for the server to access
<br/> any file with the +X filetype modifier.
<br/>
<br/> auth-check:
<br/> service-check:
<br/> Execute an authentication check trigger to verify a
<br/> user's password against an external password manager
<br/> during login or when setting a new password.
<br/>
<br/> auth-check-sso:
<br/> Facilitate a single sign-on user authentication. This
<br/> configuration requires two programs or scripts to run;
<br/> one on the client, the other on the server.
<br/>
<br/> client:
<br/> Set the environment variable 'P4LOGINSSO' to point to
<br/> a script that can be executed to obtain the user's
<br/> credentials or other information that the server
<br/> trigger can verify. The client-side script must
<br/> write the message to the standard output
<br/> (max length 128K).
<br/>
<br/> Example: P4LOGINSSO=/Users/joe/bin/runsso
<br/>
<br/> The two variables available to this trigger are
<br/> %P4PORT% and %serverAddress%. The distinction is
<br/> that serverAddress is the address of the target server
<br/> and the P4PORT is what the client is connecting to,
<br/> which might be an intermediate like a Perforce Proxy.
<br/>
<br/> These variables can be passed to the client script by
<br/> appending them to the client command string, as in:
<br/>
<br/> P4LOGINSSO="/Users/joe/bin/runsso %serverAddress%"
<br/>
<br/> server:
<br/> Execute an authentication (sso) trigger that gets
<br/> this message from the standard input and returns an
<br/> exit status of 0 (for verified) or otherwise failed.
<br/>
<br/> Example:
<br/> sso auth-check-sso auth "/secure/verify %user%"
<br/>
<br/> The user must issue the 'p4 login' command, but no
<br/> password prompting is invoked. If the server
<br/> determines that the user is valid, they are issued a
<br/> Perforce ticket just as if they had logged in with a
<br/> password.
<br/>
<br/> Pre-2007.2 clients cannot run a client-side single
<br/> sign-on. Specifying an 'auth-check' trigger as a backup
<br/> for a user to gain access will prompt the user for a
<br/> password if it's an older client or P4LOGINSSO has not
<br/> been configured.
<br/>
<br/> Unlike passwords which are encrypted, the sso message is
<br/> sent to the server in clear text.
<br/>
<br/> auth-set:
<br/> Execute an authentication set trigger to send a new
<br/> password to an external password manager.
<br/>
<br/> change-submit:
<br/> Execute pre-submit trigger after changelist has been
<br/> created and files locked but prior to file transfer.
<br/>
<br/> change-content:
<br/> Execute mid-submit trigger after file transfer but prior
<br/> to commit. Files can be accessed by the 'p4 diff2',
<br/> 'p4 files', 'p4 fstat', and 'p4 print' commands using
<br/> the revision specification '@=change', where 'change' is
<br/> the pending changelist number passed as %changelist%.
<br/>
<br/> change-commit:
<br/> Execute post-submit trigger after changelist commit.
<br/>
<br/> change-failed:
<br/> Executes only if the changelist commit failed.
<br/> Note that this trigger only fires on errors
<br/> occurring after a commit process has started. It does
<br/> not fire for early usage errors, or due to errors from
<br/> the submit form. In short, if a change-* trigger
<br/> could have run, then the change-failed trigger
<br/> will fire if that commit fails.
<br/>
<br/> command:
<br/> Execute pre/post trigger when users run commands.
<br/>
<br/> edge-submit:
<br/> Execute pre-submit trigger on Edge Server after changelist
<br/> has been created but prior to file transfer.
<br/>
<br/> edge-content:
<br/> Execute mid-submit trigger on Edge Server after file
<br/> transfer but prior to beginning submit on Commit Server.
<br/>
<br/> fix-add:
<br/> Execute fix trigger prior to adding a fix. The special
<br/> variable %jobs% is available for expansion and must be
<br/> the last argument to the trigger as it expands to one
<br/> argument for each job listed on the 'p4 fix' command.
<br/>
<br/> fix-delete:
<br/> Execute fix trigger prior to deleting a fix. The special
<br/> variable %jobs% is available for expansion and must be
<br/> the last argument to the trigger as it expands to one
<br/> argument for each job listed on the 'p4 fix -d' command.
<br/>
<br/> form-out:
<br/> Execute form trigger on generation of form. Trigger may
<br/> modify form.
<br/>
<br/> form-in:
<br/> Execute form trigger on input of form before its contents
<br/> are parsed and validated. Trigger may modify form.
<br/>
<br/> form-save:
<br/> Execute form trigger prior to save of form after its
<br/> contents are parsed.
<br/>
<br/> form-commit:
<br/> Execute form trigger after it has been committed, allowing
<br/> access to automatically generated fields (jobname, dates
<br/> etc). It cannot modify the form. This trigger for job
<br/> forms is run by 'p4 job' and 'p4 fix' (after the status
<br/> is updated), 'p4 change' (if the job is added or deleted)
<br/> and 'p4 submit' (if the job is associated with the change).
<br/> The 'form-commit' trigger has access to the new job name
<br/> created with 'p4 job', while the 'form-in' and 'form-save'
<br/> triggers are run before the job name is created. The
<br/> special variable %action% is available on the job
<br/> 'form-commit' trigger command line, and is expanded when
<br/> the job is modified by a fix.
<br/>
<br/> form-delete:
<br/> Execute form trigger prior to delete of form after its
<br/> contents are parsed.
<br/>
<br/> shelve-submit:
<br/> Execute pre-shelve trigger after changelist has been
<br/> created but prior to file transfer.
<br/>
<br/> shelve-commit:
<br/> Execute post-shelve trigger after files are shelved.
<br/>
<br/> shelve-delete:
<br/> Execute shelve trigger prior to discarding shelved files.
<br/>
<br/> Path: For change and submit triggers, a file pattern to match files
<br/> in the changelist. This file pattern can be an exclusion
<br/> mapping (-pattern), to exclude files. For form triggers, the
<br/> name of the form (branch, client, etc). For fix triggers
<br/> 'fix' is required as the path value. For authentication
<br/> triggers, 'auth' is required as the path value. For archive
<br/> triggers, a file pattern to match the name of the file being
<br/> accessed in the archive. Note that, due to lazy copying when
<br/> branching files, the name of the file in the archive can not
<br/> be the same as the name of the file in the depot. For command
<br/> triggers, use the name of the command to match, e.g.
<br/> 'pre-user-$cmd' or a regular expression, e.g.
<br/> '(pre|post)-user-add'.
<br/>
<br/> Command: The OS command to run for validation. If the command
<br/> contains spaces, enclose it in double quotes. The
<br/> following variables are expanded in the command string.
<br/> Use of the triggers.io configurable with a value greater than
<br/> zero is recommended, as some vars may be empty or contain
<br/> shell metacharacters.
<br/>
<br/> %//depot/trigger.exe% -- depot paths within %vars%
<br/> are filled with the path to a temporary file containing
<br/> the referenced file's contents. Only standard and stream
<br/> depot files whose contents is available are valid.
<br/> %argc% -- number of command arguments
<br/> %args% -- command argument string
<br/> %argsQuoted% -- command argument string, CSV delimited
<br/> %client% -- the client issuing the command
<br/> %clientcwd% -- client current working directory
<br/> %clienthost% -- the hostname of the client
<br/> %clientip% -- the IP address of the client
<br/> %clientprog% -- the program name of the client
<br/> %clientversion% -- the version of the client
<br/> %command% -- name of command being run
<br/> %groups% -- list of groups user is a member of
<br/> %intermediateService% -- presence of a Broker/Proxy/etc
<br/> %maxErrorSeverity% -- highest error seen for this cmd
<br/> %maxErrorText% -- text and errno for highest error
<br/> %maxLockTime% -- user-specified override of group value
<br/> %maxResults% -- user-specified override of group value
<br/> %maxScanRows% -- user-specified override of group value
<br/> %quote% -- double quote character
<br/> %serverhost% -- the hostname of the server
<br/> %serverid% -- the value of the server's server.id
<br/> %serverip% -- the IP address of the server
<br/> %servername% -- the value of the server's $P4NAME
<br/> %serverpid% -- the PID of the server
<br/> %serverport% -- the IP address:port of the server
<br/> preceded by the transport prefix,
<br/> if needed (i.e. P4PORT)
<br/> %serverroot% -- the value of the server's $P4ROOT
<br/> %serverservices% -- the services provided by the server
<br/> %serverVersion% -- the server's version string
<br/> %terminated% -- if the command was forced to quit early
<br/> %termReason% -- reason for early termination
<br/> %triggerMeta_action% -- command to execute by trigger
<br/> %triggerMeta_depotFile% -- third field in trigger def.
<br/> %triggerMeta_name% -- name from trigger definition
<br/> %triggerMeta_trigger% -- second field in trigger definition
<br/> %user% -- the user issuing the command
<br/>
<br/> %changelist% -- the changelist being submitted
<br/> %changeroot% -- the root path of files submitted
<br/> %oldchangelist% -- the pre-commit changelist number
<br/>
<br/> (More information can be gathered about the
<br/> changelist being submitted by running
<br/> 'p4 describe %changelist%'.)
<br/>
<br/> %formfile% -- path to temp file containing form
<br/> %formname% -- the form's name (branch name, etc)
<br/> %formtype% -- the type of form (branch, etc)
<br/> %action% -- added/deleted/submitted on job form-commit
<br/>
<br/> %jobs% -- list of job names for fix triggers
<br/>
<br/> %op% -- read/write/delete for archive access
<br/> %file% -- name of archive file
<br/> %rev% -- revision of archive file
<br/>
<br/> If the command was sent via a proxy, broker, or replica:
<br/> %peerhost% -- the hostname of the proxy/broker/replica
<br/> %peerip% -- the IP address of the proxy/broker/replica
<br/> If the command was sent directly, %peerhost% and
<br/> %peerip% match %clienthost% and %clientip%.
<br/>
<br/> For a change-* trigger in a distributed installation,
<br/> %submitserverid% -- the server.id where submit was run
<br/>
<br/> For a post-rmt-Push trigger:
<br/> %firstPushedChange% -- first new changelist number
<br/> %lastPushedChange% -- last new changelist number
<br/>
<br/> Note that not all variables are available for every
<br/> trigger type. E.g. argc and argv only show up for
<br/> pre-user-$cmd and change-submit (and so on), but not for
<br/> post-user-$cmd or change-commit.
<br/>
<br/> The command's standard input depends on the value of the
<br/> triggers.io configurable. When it is set to zero, stdin is
<br/> empty for change, shelve, fix and command triggers, it
<br/> is the file content for the archive, and password for auth
<br/> triggers. When triggers.io is set to 1, stdin is a textual
<br/> dictionary containing connection information that the trigger
<br/> must read (with the exception of archive/auth triggers,
<br/> which behave the same as when triggers.io=0.)
<br/>
<br/> If the command fails, the command's standard output (not
<br/> error output) is sent to the client as the text of a trigger
<br/> failure error message.
<br/>
<br/> If the command succeeds, the command's standard output is
<br/> sent as an unadorned message to the client for all triggers
<br/> except archive triggers; for archive triggers, the command's
<br/> standard output is the file content.
<br/>
<br/> The -o flag writes the trigger table to the standard output.
<br/> The user's editor is not invoked.
<br/>
<br/> The -i flag reads the trigger table from the standard input.
<br/> The user's editor is not invoked.
<br/>
<br/> 'p4 triggers' requires 'super' access granted by 'p4 protect'.
<br/>
<br/>
</remarks>
<example>
To get the trigger table:
<code>
GetTriggerTableCmdOptions opts =
new GetTriggerTableCmdOptions(GetTriggerTableCmdFlags.Output);
IList<Trigger> target = Repository.GetTriggerTable(opts);
</code>
</example>
<seealso cref="T:Perforce.P4.GetTriggerTableCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.GetTypeMap">
<summary>
Get the repository's type map.
</summary>
<returns></returns>
<remarks>
runs the command p4 typemap -o
</remarks>
<remarks>
<br/><b>p4 help typemap</b>
<br/>
<br/> typemap -- Edit the filename-to-filetype mapping table
<br/>
<br/> p4 typemap
<br/> p4 typemap -o
<br/> p4 typemap -i
<br/>
<br/> 'p4 typemap' edits a name-to-type mapping table for 'p4 add', which
<br/> uses the table to assign a file's filetype based on its name.
<br/>
<br/> The typemap form has a single field, 'TypeMap', followed by any
<br/> number of typemap lines. Each typemap line contains a filetype
<br/> and a depot file path pattern:
<br/>
<br/> Filetype: See 'p4 help filetypes' for a list of valid filetypes.
<br/>
<br/> Path: Names to be mapped to the filetype. The mapping is
<br/> a file pattern in depot syntax. When a user adds a file
<br/> matching this pattern, its default filetype is the
<br/> file type specified in the table. To exclude files from
<br/> the typemap, use exclusionary (-pattern) mappings.
<br/> To match all files anywhere in the depot hierarchy,
<br/> the pattern must begin with '//...'. To match files
<br/> with a specified suffix, use '//.../*.suffix' or
<br/> use '//....suffix' (four dots).
<br/>
<br/> Later entries override earlier entries. If no matching entry is found
<br/> in the table, 'p4 add' determines the filetype by examining the file's
<br/> contents and execution permission bits.
<br/>
<br/> The -o flag writes the typemap table to standard output. The user's
<br/> editor is not invoked.
<br/>
<br/> The -i flag reads the typemap table from standard input. The user's
<br/> editor is not invoked.
<br/>
<br/> 'p4 typemap' requires 'admin' access, which is granted by 'p4 protect'.
<br/>
<br/>
</remarks>
<example>
To get the typemap table:
<code>
IList<TypeMapEntry> target = Repository.GetTypeMap();
</code>
</example>
</member>
<member name="M:Perforce.P4.Repository.GetProtectionTable(Perforce.P4.Options)">
<summary>
Get the repository's protection table.
</summary>
<param name="options"></param>
<returns></returns>
<remarks>
<br/><b>p4 help protect</b>
<br/>
<br/> protect -- Modify protections in the server namespace
<br/>
<br/> p4 protect
<br/> p4 protect -o
<br/> p4 protect -i
<br/>
<br/> 'p4 protect' edits the protections table in a text form.
<br/>
<br/> Each line in the table contains a protection mode, a group/user
<br/> indicator, the group/user name, client host ID and a depot file
<br/> path pattern. Users receive the highest privilege that is granted
<br/> on any line.
<br/>
<br/> Note: remote depots are accessed using the pseudo-user 'remote'.
<br/> To control access from other servers that define your server as
<br/> a remote server, grant appropriate permissions to the 'remote' user.
<br/>
<br/> Mode: The permission level or right being granted or denied.
<br/> Each permission level includes all the permissions above
<br/> it, except for 'review'. Each permission only includes
<br/> the specific right and no lesser rights. This approach
<br/> enables you to deny individual rights without having to
<br/> re-grant lesser rights. Modes prefixed by '=' are rights.
<br/> All other modes are permission levels.
<br/>
<br/> Valid modes are:
<br/>
<br/> list - users can see names but not contents of files;
<br/> users can see all non-file related metadata
<br/> (clients, users, changelists, jobs, etc.)
<br/>
<br/> read - users can sync, diff, and print files
<br/>
<br/> open - users can open files (add, edit. delete,
<br/> integrate)
<br/>
<br/> write - users can submit open files
<br/>
<br/> admin - permits those administrative commands and
<br/> command options that don't affect the server's
<br/> security.
<br/>
<br/> super - access to all commands and command options.
<br/>
<br/> review - permits access to the 'p4 review' command;
<br/> implies read access
<br/>
<br/> =read - if this right is denied, users can't sync,
<br/> diff, or print files
<br/>
<br/> =branch - if this right is denied, users are not
<br/> permitted to use files as a source
<br/> for 'p4 integrate'
<br/>
<br/> =open = if this right is denied, users cannot open
<br/> files (add, edit, delete, integrate)
<br/>
<br/> =write = if this right is denied, users cannot submit
<br/> open files
<br/>
<br/> Group/User indicator: specifies the grantee is a group or user.
<br/>
<br/> Name: A Perforce group or user name; can include wildcards.
<br/>
<br/> Host: The IP address of a client host; can include wildcards.
<br/>
<br/> The server can distinguish connections coming from a
<br/> proxy, broker, or replica. The server prepends the string
<br/> 'proxy-' to the IP address of the true client of such
<br/> a connection when the server enforces the protections.
<br/>
<br/> Specify the 'proxy-' prefix for the IP address in the
<br/> Host: field in the protections table to indicate the
<br/> protections that should thus apply.
<br/>
<br/> For example, 'proxy-*' applies to all connections from
<br/> all proxies, brokers, and replicas, while
<br/> 'proxy-10.0.0.5' identifies a client machine with an IP
<br/> address of 10.0.0.5 which is connecting to p4d through
<br/> a proxy, broker, or replica.
<br/>
<br/> If you wish to write a single set of protections entries
<br/> which apply both to directly-connected clients as well
<br/> as to those which connect via a proxy, broker, or
<br/> replica, you can omit the 'proxy-' prefix and also set
<br/> dm.proxy.protects=0. In this case, the 'proxy-' prefix
<br/> is not prepended to the IP address of connections which
<br/> are made via a proxy, replica or broker. Note that in
<br/> this scenario, all intermediate proxies, brokers, and
<br/> replicas should be at release 2012.1 or higher.
<br/>
<br/> Path: The part of the depot to which access is being granted
<br/> or denied. To deny access to a depot path, preface the
<br/> path with a "-" character. These exclusionary mappings
<br/> apply to all access levels, even if only one access
<br/> level is specified in the first field.
<br/>
<br/> The -o flag writes the protection table to the standard output.
<br/> The user's editor is not invoked.
<br/>
<br/> The -i flag reads the protection table from the standard input.
<br/> The user's editor is not invoked.
<br/>
<br/> After protections are defined, 'p4 protect' requires 'super'
<br/> access.
<br/>
<br/>
</remarks>
<example>
To get the protections table:
<code>
GetProtectionTableCmdOptions opts =
new GetProtectionTableCmdOptions(GetProtectionTableCmdFlags.Output);
IList<ProtectionEntry> target = Repository.GetProtectionTable(opts);
</code>
</example>
<seealso cref="T:Perforce.P4.GetProtectionTableCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.GetCounters(Perforce.P4.Options)">
<summary>
Get the Perforce counters for this repository.
</summary>
<param name="options"></param>
<returns></returns>
<remarks>
<br/><b>p4 help counters</b>
<br/>
<br/> counters -- Display list of known counters
<br/>
<br/> p4 counters [-e nameFilter -m max]
<br/>
<br/> Lists the counters in use by the server. The server
<br/> uses the following counters directly:
<br/>
<br/> change Current change number
<br/> job Current job number
<br/> journal Current journal number
<br/> lastCheckpointAction Data about the last complete checkpoint
<br/> logger Event log index used by 'p4 logger'
<br/> traits Internal trait lot number used by 'p4 attribute'
<br/> upgrade Server database upgrade level
<br/>
<br/> The -e nameFilter flag lists counters with a name that matches
<br/> the nameFilter pattern, for example: -e 'mycounter-*'.
<br/>
<br/> The -m max flag limits the output to the first 'max' counters.
<br/>
<br/> The names 'minClient', 'minClientMessage', 'monitor',
<br/> 'security', 'masterGenNumber', and 'unicode' are reserved names:
<br/> do not use them as ordinary counters.
<br/>
<br/> For general-purpose server configuration, see 'p4 help configure'.
<br/>
<br/>
</remarks>
<example>
To get the counters on the server:
<code>
IList<Counter> target = Repository.GetCounters(null);
</code>
To get the counters on the server that start with the name "build_":
<code>
Options opts = new Options();
opts["-e"] = "build_*";
IList<Counter> target = Repository.GetCounters(opts);
</code>
</example>
</member>
<member name="M:Perforce.P4.Repository.GetCounter(System.String,Perforce.P4.Options)">
<summary>
Get a named Perforce counter value from the repository.
</summary>
<param name="name"></param>
<param name="options"></param>
<returns></returns>
<remarks>
<br/><b>p4 help counter</b>
<br/>
<br/> counter -- Display, set, or delete a counter
<br/>
<br/> p4 counter name
<br/> p4 counter [-f] name value
<br/> p4 counter [-f] -d name
<br/> p4 counter [-f] -i name
<br/> p4 counter [-f] -m [ pair list ]
<br/>
<br/> The first form displays the value of the specified counter.
<br/>
<br/> The second form sets the counter to the specified value.
<br/>
<br/> The third form deletes the counter. This option usually has the
<br/> same effect as setting the counter to 0.
<br/>
<br/> The -f flag sets or deletes counters used by Perforce, which are
<br/> listed by 'p4 help counters'. Important: Never set the 'change'
<br/> counter to a value that is lower than its current value.
<br/>
<br/> The -i flag increments a counter by 1 and returns the new value.
<br/> This option is used instead of a value argument and can only be
<br/> used with numeric counters.
<br/>
<br/> The fifth form allows multiple operations in one command.
<br/> With this, the list is pairs of arguments. Each pair is either
<br/> counter value or '-' counter. To set a counter use a name and value.
<br/> To delete a counter use a '-' followed by the name.
<br/>
<br/> Counters can be assigned textual values as well as numeric ones,
<br/> despite the name 'counter'.
<br/>
<br/> 'p4 counter' requires 'review' access granted by 'p4 protect'.
<br/> The -f flag requires that the user be an operator or have 'super'
<br/> access.
<br/>
<br/>
</remarks>
<example>
To get the job counter:
<code>
Counter target = Repository.GetCounter("job", null);
</code>
To get the change counter:
<code>
Counter target = Repository.GetCounter("change", null);
</code>
To get the journal counter:
<code>
Counter target = Repository.GetCounter("journal", null);
</code>
</example>
</member>
<member name="M:Perforce.P4.Repository.DeleteCounter(System.String,Perforce.P4.Options)">
<summary>
Delete a Perforce counter from the repository.
</summary>
<param name="name"></param>
<param name="options"></param>
<returns></returns>
<remarks>
<br/><b>p4 help counter</b>
<br/>
<br/> counter -- Display, set, or delete a counter
<br/>
<br/> p4 counter name
<br/> p4 counter [-f] name value
<br/> p4 counter [-f] -d name
<br/> p4 counter [-f] -i name
<br/> p4 counter [-f] -m [ pair list ]
<br/>
<br/> The first form displays the value of the specified counter.
<br/>
<br/> The second form sets the counter to the specified value.
<br/>
<br/> The third form deletes the counter. This option usually has the
<br/> same effect as setting the counter to 0.
<br/>
<br/> The -f flag sets or deletes counters used by Perforce, which are
<br/> listed by 'p4 help counters'. Important: Never set the 'change'
<br/> counter to a value that is lower than its current value.
<br/>
<br/> The -i flag increments a counter by 1 and returns the new value.
<br/> This option is used instead of a value argument and can only be
<br/> used with numeric counters.
<br/>
<br/> The fifth form allows multiple operations in one command.
<br/> With this, the list is pairs of arguments. Each pair is either
<br/> counter value or '-' counter. To set a counter use a name and value.
<br/> To delete a counter use a '-' followed by the name.
<br/>
<br/> Counters can be assigned textual values as well as numeric ones,
<br/> despite the name 'counter'.
<br/>
<br/> 'p4 counter' requires 'review' access granted by 'p4 protect'.
<br/> The -f flag requires that the user be an operator or have 'super'
<br/> access.
<br/>
<br/>
</remarks>
<example>
To delete a counter named test:
<code>
Counter target = Repository.DeleteCounter("test", null);
</code>
To delete a counter named build using -f with a user with
super access:
<code>
Options opts = new Options();
opts["-f"] = null;
Counter target = Repository.DeleteCounter("build", opts);
</code>
</example>
</member>
<member name="M:Perforce.P4.Repository.CreateLabel(Perforce.P4.Label,Perforce.P4.Options)">
<summary>
Create a new label in the repository.
</summary>
<param name="label">Label specification for the new label</param>
<param name="options">The '-i' flag is required when creating a new label </param>
<returns>The Label object if new label was created, null if creation failed</returns>
<remarks> The '-i' flag is added if not specified by the caller
<br/>
<br/><b>p4 help label</b>
<br/>
<br/> label -- Create or edit a label specification
<br/>
<br/> p4 label [-f -g -t template] name
<br/> p4 label -d [-f -g] name
<br/> p4 label -o [-t template] name
<br/> p4 label -i [-f -g]
<br/>
<br/> Create or edit a label. The name parameter is required. The
<br/> specification form is put into a temporary file and the editor
<br/> (configured by the environment variable $P4EDITOR) is invoked.
<br/>
<br/> The label specification form contains the following fields:
<br/>
<br/> Label: The label name (read only.)
<br/>
<br/> Owner: The user who created this label. Can be changed.
<br/>
<br/> Update: The date that this specification was last modified.
<br/>
<br/> Access: The date of the last 'labelsync' or use of '@label'
<br/> referencing this label.
<br/>
<br/> Description: A short description of the label (optional).
<br/>
<br/> Options: Flags to change the label behavior.
<br/>
<br/> locked Prevents users other than the label owner
<br/> unlocked from changing the specification. Prevents
<br/> the label from being deleted. Prevents the
<br/> owner from running 'p4 labelsync'. For a
<br/> loaded label, prevents 'p4 unload'.
<br/>
<br/> autoreload For a static label, indicates where label
<br/> noautoreload revisions are stored. Specify 'noautoreload'
<br/> to indicate that the revisions should be
<br/> stored in the db.label table. Specify
<br/> 'autoreload' to indicate that the revisions
<br/> should be stored in the unload depot.
<br/>
<br/> Revision: An optional revision specification for an automatic
<br/> label. Enclose in double quotes if it contains the
<br/> # (form comment) character. An automatic label can
<br/> be treated as a pure alias of a single revision
<br/> specification (excluding @label) provided that the
<br/> View mapping is empty.
<br/>
<br/> View: A mapping that selects files from the depot. The
<br/> default view selects all depot files. Only the left
<br/> side of the mapping is used for labels. Leave this
<br/> field blank when creating an automatic label as
<br/> a pure alias. See 'p4 help views'.
<br/>
<br/> ServerID: If set, restricts usage to the named server.
<br/> If unset, usage is allowed on any server.
<br/>
<br/> A label is a named collection of revisions. A label is either
<br/> automatic or static. An automatic label refers to the revisions
<br/> given in the View: and Revision: fields. A static label refers to
<br/> the revisions that are associated with the label using the 'p4 tag'
<br/> or 'p4 labelsync' commands. A static label cannot have a Revison:
<br/> field. See 'p4 help revisions' for information on using labels as
<br/> revision specifiers.
<br/>
<br/> Only the label owner can run 'p4 labelsync', and only if the label
<br/> is unlocked. A label without an owner can be labelsync'd by any user.
<br/>
<br/> Flag -d deletes the specified label. You cannot delete a locked label.
<br/> The -f flag forces the delete.
<br/>
<br/> The -o flag writes the label specification to standard output. The
<br/> user's editor is not invoked.
<br/>
<br/> The -i flag reads a label specification from standard input. The
<br/> user's editor is not invoked.
<br/>
<br/> The -t flag copies the view and options from the template label to
<br/> the new label.
<br/>
<br/> The -f flag forces the deletion of a label. By default, locked labels
<br/> can only be deleted by their owner. The -f flag also permits the
<br/> Last Modified date to be set. The -f flag requires 'admin' access,
<br/> which is granted by 'p4 protect'.
<br/>
<br/> The -g flag should be used on an Edge Server to update a global
<br/> label. Without -g, the label definition is visible only to users
<br/> of this Edge Server. Configuring rpl.labels.global=1 reverses this
<br/> default and causes this flag to have the opposite meaning.
<br/>
<br/>
</remarks>
<example>
To create a new label:
<code>
Label l = new Label();
l.Id = "newLabel";
l.Owner = "admin";
l.Description = "created by admin";
l.Options = "unlocked";
l.ViewMap = new ViewMap();
string v0 = "//depot/main/...";
string v1 = "//depot/rel1/...";
string v2 = "//depot/rel2/...";
string v3 = "//depot/dev/...";
l.ViewMap.Add(v0);
l.ViewMap.Add(v1);
l.ViewMap.Add(v2);
l.ViewMap.Add(v3);
Label newLabel = rep.CreateLabel(l, null);
</code>
To create a label using another label as a template:
<code>
Label newLabel2 = rep.CreateLabel(newLabel,
new LabelCmdOptions(LabelCmdFlags.None, newLabel.Id));
</code>
</example>
</member>
<member name="M:Perforce.P4.Repository.CreateLabel(Perforce.P4.Label)">
<summary>
Create a new label in the repository.
</summary>
<param name="label">Label specification for the new label</param>
<returns>The Label object if new label was created, null if creation failed</returns>
<example>
To create a new label:
<code>
Label l = new Label();
l.Id = "newLabel";
l.Owner = "admin";
l.Description = "created by admin";
l.Options = "unlocked";
l.ViewMap = new ViewMap();
string v0 = "//depot/main/...";
string v1 = "//depot/rel1/...";
string v2 = "//depot/rel2/...";
string v3 = "//depot/dev/...";
l.ViewMap.Add(v0);
l.ViewMap.Add(v1);
l.ViewMap.Add(v2);
l.ViewMap.Add(v3);
Label newLabel = rep.CreateLabel(l, null);
</code>
</example>
</member>
<member name="M:Perforce.P4.Repository.UpdateLabel(Perforce.P4.Label)">
<summary>
Update the record for a label in the repository
</summary>
<param name="label">Label specification for the label being updated</param>
<returns>The Label object if new depot was saved, null if creation failed</returns>
<example>
To lock a label:
<code>
Label l = rep.GetLabel("admin_label");
l.Locked = true;
rep.UpdateLabel(l);
</code>
</example>
</member>
<member name="M:Perforce.P4.Repository.GetLabel(System.String,System.String,Perforce.P4.Options)">
<summary>
Get the record for an existing label from the repository.
</summary>
<param name="label">Label name</param>
<param name="options">Flags used when fetching an existing label</param>
<returns>The Label object if label was found, null if creation failed</returns>
<example>
To get the admin_label with the gobal option:
<code>
LabelCmdOptions opts = new LabelCmdOptions(LabelCmdFlags.Global,null);
Label label = rep.GetLabel("admin_label", null, opts);
</code>
</example>
</member>
<member name="M:Perforce.P4.Repository.GetLabel(System.String)">
<summary>
Get the record for an existing label from the repository.
</summary>
<param name="label">Label name</param>
<returns>The Label object if label was found, null if creation failed</returns>
<example>
To get the admin_label:
<code>
string targetLabel = "admin_label";
Label l = rep.GetLabel(targetLabel);
</code>
</example>
</member>
<member name="M:Perforce.P4.Repository.GetLabels(Perforce.P4.Options,Perforce.P4.FileSpec[])">
<summary>
Get a list of labels from the repository
</summary>
<returns>A list containing the matching labels</returns>
<remarks>
<br/><b>p4 help labels</b>
<br/>
<br/> labels -- Display list of defined labels
<br/>
<br/> p4 labels [-t] [-u user] [[-e|-E] nameFilter -m max] [file[revrange]]
<br/> p4 labels [-t] [-u user] [[-e|-E] nameFilter -m max] [-a|-s serverID]
<br/> p4 labels -U
<br/>
<br/> Lists labels defined in the server.
<br/>
<br/> If files are specified, 'p4 labels' lists the labels that contain
<br/> those files. If you include a file specification, automatic labels
<br/> and labels with the 'autoreload' option set are omitted from the list.
<br/> If the file specification includes a revision range, 'p4 labels'
<br/> lists labels that contain the specified revisions.
<br/>
<br/> See 'p4 help revisions' for details about specifying revisions.
<br/>
<br/> The -t flag displays the time as well as the date.
<br/>
<br/> The -u user flag lists labels owned by the specified user.
<br/>
<br/> The -e nameFilter flag lists labels with a name that matches
<br/> the nameFilter pattern, for example: -e 'svr-dev-rel*'. The -e flag
<br/> uses the server's normal case-sensitivity rules. The -E flag makes
<br/> the matching case-insensitive, even on a case-sensitive server.
<br/>
<br/> The -m max flag limits output to the first 'max' number of labels.
<br/>
<br/> The -U flag lists unloaded labels (see 'p4 help unload').
<br/>
<br/> The -a and -s flags are useful in a distributed server installation
<br/> (see 'p4 help distributed') in order to see the names of local labels
<br/> stored on other Edge Servers. These flags are not allowed if the
<br/> command includes a file specification.
<br/>
<br/> The -a flag specifies that all labels should be displayed, not just
<br/> those that are bound to this server.
<br/>
<br/> The -s serverID flag specifies that only those labels bound to the
<br/> specified serverID should be displayed.
<br/>
<br/> On an Edge Server, if neither -s nor -a is specified, only those
<br/> local labels bound to this Edge Server are displayed. Labels created
<br/> on the Commit Server are global, and are also included in the output.
<br/>
<br/>
</remarks>
<example>
To get 50 labels on a distributed server installation:
<code>
LabelsCmdOptions opts = new LabelsCmdOptions(LabelsCmdFlags.All,
null, null, 50, null, null);
IList<Label> labels = rep.GetLabels(opts);
</code>
To get labels which contain files with the path //depot/Modifiers/...:
<code>
FileSpec path = new FileSpec(new DepotPath("//depot/Modifiers/..."), null);
Options ops = new Options();
IList<Label> l = rep.GetLabels(ops, path);
</code>
</example>
</member>
<member name="M:Perforce.P4.Repository.DeleteLabel(Perforce.P4.Label,Perforce.P4.Options)">
<summary>
Delete a label from the repository
</summary>
<param name="label">The label to be deleted</param>
<param name="options">The 'f' and '-d' flags are valid when deleting an
existing label</param>
<example>
To delete the label admin_label:
<code>
Label deleteTarget = new Label();
deleteTarget.Id = "admin_label";
rep.DeleteLabel(deleteTarget, null);
</code>
</example>
</member>
<member name="M:Perforce.P4.Repository.CreateStream(Perforce.P4.Stream,Perforce.P4.Options)">
<summary>
Create a new stream in the repository.
</summary>
<param name="stream">Stream specification for the new stream</param>
<param name="options">The '-i' flag is required when creating a new stream</param>
<returns>The Stream object if new stream was created, null if creation failed</returns>
<remarks> The '-i' flag is added if not specified by the caller
<br/>
<br/><b>p4 help stream</b>
<br/>
<br/> stream -- Create, delete, or modify a stream specification
<br/>
<br/> p4 stream [-P parent] -t type name
<br/> p4 stream [-f] [-d] [-o [-v]] [-P parent] -t type name
<br/> p4 stream -i [-f]
<br/>
<br/> A stream specification ('spec') names a path in a stream depot to be
<br/> treated as a stream. (See 'p4 help streamintro'.) The spec also
<br/> defines the stream's lineage, its view, and its expected flow of
<br/> change.
<br/>
<br/> The 'p4 stream' command puts the stream spec into a temporary file and
<br/> invokes the editor configured by the environment variable $P4EDITOR.
<br/> When creating a stream, the type of the stream must be specified with
<br/> the '-t' flag. Saving the file creates or modifies the stream spec.
<br/>
<br/> Creating a stream spec does not branch a new stream. To branch a
<br/> stream, use 'p4 copy -r -S stream', where 'stream' is the name of a
<br/> stream spec.
<br/>
<br/> The stream spec contains the following fields:
<br/>
<br/> Stream: The stream's path in a stream depot, of the form
<br/> //depotname/streamname. This is both the name of the stream
<br/> spec and the permanent, unique identifier of the stream.
<br/>
<br/> Update: The date this stream spec was last changed.
<br/>
<br/> Access: The date of the last command used with this spec.
<br/>
<br/> Owner: The stream's owner. A stream can be owned by a user, or
<br/> owned by a group. Can be changed.
<br/>
<br/> Name: An alternate name of the stream, for use in display outputs.
<br/> Defaults to the 'streamname' portion of the stream path.
<br/> Can be changed.
<br/>
<br/> Parent: The parent of this stream. Can be 'none' if the stream type
<br/> is 'mainline', otherwise must be set to an existing stream
<br/> identifier, of the form //depotname/streamname.
<br/> Can be changed.
<br/>
<br/> Type: 'mainline', 'virtual', 'development', 'release' or 'task'.
<br/> Defines the role of a stream: A 'mainline' may not have a
<br/> parent. A 'virtual' stream is not a stream but an alternate
<br/> view of its parent stream. The 'development' and 'release'
<br/> streams have controlled flow. Can be changed. A 'task'
<br/> stream is a lightweight short-lived stream that only
<br/> promotes edited files to the repository; branched and
<br/> integrated files are stored in shadow tables that are
<br/> removed when the task stream is deleted or unloaded.
<br/>
<br/> Flow control is provided by 'p4 copy -S' and 'p4 merge -S'.
<br/> These commands restrict the flow of change as follows:
<br/>
<br/> Stream Type Direction of flow Allowed with
<br/> ----------- ----------------- ------------
<br/> development to parent stream 'p4 copy'
<br/> task to parent stream 'p4 copy'
<br/> release to parent stream 'p4 merge'
<br/> development from parent stream 'p4 merge'
<br/> release from parent stream 'p4 copy'
<br/>
<br/> Description: An optional description of the stream.
<br/>
<br/> Options: Flags to configure stream behavior. Defaults are marked *:
<br/>
<br/> unlocked * Indicates whether the stream spec is locked
<br/> locked against modifications. If locked, the spec
<br/> may not be deleted, and only its owner or
<br/> group users can modify it.
<br/>
<br/> allsubmit * Indicates whether all users or only the
<br/> ownersubmit owner (or group users) of the stream may
<br/> submit changes to the stream path.
<br/>
<br/> toparent * Indicates if controlled flow from the
<br/> notoparent stream to its parent is expected to occur.
<br/>
<br/> fromparent * Indicates if controlled flow to the stream
<br/> nofromparent from its parent is expected to occur.
<br/>
<br/> mergedown * Indicates if merge flow is restricted or
<br/> mergeany merge is permitted from any other stream.
<br/>
<br/> The [no]fromparent and [no]toparent options determine if
<br/> 'p4 copy -S' and 'p4 merge -S' allow change to flow between
<br/> a stream and its parent. A 'virtual' stream must have its
<br/> flow options set as 'notoparent' and 'nofromparent'. Flow
<br/> options are ignored for 'mainline' streams.
<br/>
<br/> Paths: One or more lines that define file paths in the stream view.
<br/> Each line is of the form:
<br/>
<br/> <path_type> <view_path> [<depot_path>]
<br/>
<br/> where <path_type> is a single keyword, <view_path> is a file
<br/> path with no leading slashes, and the optional <depot_path>
<br/> is a file path beginning with '//'. Both <view_path> and
<br/> <depot_path> may contain trailing wildcards, but no leading
<br/> or embedded wildcards. Lines in the Paths field may appear
<br/> in any order. A duplicated <view_path> overrides its
<br/> preceding entry.
<br/>
<br/> For example:
<br/>
<br/> share src/...
<br/> import lib/abc/... //over/there/abc/...
<br/> isolate bin/*
<br/>
<br/> Default is:
<br/>
<br/> share ...
<br/>
<br/> The <path_type> keyword must be one of:
<br/>
<br/> share: <view_path> will be included in client views and
<br/> in branch views. Files in this path are accessible
<br/> to workspaces, can be submitted to the stream, and
<br/> can be integrated with the parent stream.
<br/>
<br/> isolate: <view_path> will be included in client views but
<br/> not in branch views. Files in this path are
<br/> accessible to workspaces, can be submitted to the
<br/> stream, but are not integratable with the parent
<br/> stream.
<br/>
<br/> import: <view_path> will be included in client views but
<br/> not in branch views. Files in this path are mapped
<br/> as in the parent stream's view (the default) or to
<br/> <depot_path> (optional); they are accessible to
<br/> workspaces, but can not be submitted or integrated
<br/> to the stream. If <depot_path> is used it may
<br/> include a changelist specifier; clients of that
<br/> stream will be limited to seeing revisions at that
<br/> change or lower within that depot path.
<br/>
<br/> import+: <view_path> same as 'import' except that files can
<br/> be submitted to the import path.
<br/>
<br/> exclude: <view_path> will be excluded from client views
<br/> and branch views. Files in this path are not
<br/> accessible to workspaces, and can't be submitted
<br/> or integrated to the stream.
<br/>
<br/> Paths are inherited by child stream views. A child stream's
<br/> paths can downgrade the inherited view, but not upgrade it.
<br/> (For instance, a child stream can downgrade a shared path to
<br/> an isolated path, but it can't upgrade an isolated path to a
<br/> shared path.) Note that <depot_path> is relevant only when
<br/> <path_type> is 'import'.
<br/>
<br/> Remapped: Optional; one or more lines that define how stream view paths
<br/> are to be remapped in client views. Each line is of the form:
<br/>
<br/> <view_path_1> <view_path_2>
<br/>
<br/> where <view_path_1> and <view_path_2> are Perforce view paths
<br/> with no leading slashes and no leading or embedded wildcards.
<br/> For example:
<br/>
<br/> ... x/...
<br/> y/* y/z/*
<br/>
<br/> Line ordering in the Remapped field is significant; if more
<br/> than one line remaps the same files, the later line has
<br/> precedence. Remapping is inherited by child stream client
<br/> views.
<br/>
<br/> Ignored: Optional; a list of file or directory names to be ignored in
<br/> client views. For example:
<br/>
<br/> /tmp # ignores files named 'tmp'
<br/> /tmp/... # ignores dirs named 'tmp'
<br/> .tmp # ignores file names ending in '.tmp'
<br/>
<br/> Lines in the Ignored field may appear in any order. Ignored
<br/> names are inherited by child stream client views.
<br/>
<br/> The -d flag causes the stream spec to be deleted. A stream spec may
<br/> not be deleted if it is referenced by child streams or stream clients.
<br/> Deleting a stream spec does not remove stream files, but it does mean
<br/> changes can no longer be submitted to the stream's path.
<br/>
<br/> The -o flag causes the stream spec to be written to the standard
<br/> output. The user's editor is not invoked. -v may be used with -o to
<br/> expose the automatically generated client view for this stream.
<br/> ('p4 help branch' describes how to expose the branch view.)
<br/>
<br/> The -P flag can be used to insert a value into the Parent field of a
<br/> new stream spec. It has no effect on an existing spec.
<br/>
<br/> The -t flag is used to insert a value into the type field of a
<br/> new stream spec and to adjust the default fromparent option
<br/> for a new 'release' -type stream. The flag has no effect on an
<br/> existing spec.
<br/>
<br/> The -i flag causes a stream spec to be read from the standard input.
<br/> The user's editor is not invoked.
<br/>
<br/> The -f flag allows a user other than the owner to modify or delete a
<br/> locked stream. It requires 'admin' access granted by 'p4 protect'.
<br/>
<br/>
</remarks>
<example>
To create a new mainline stream:
<code>
Stream main = new Stream();
string mainTargetId = "//Rocket/mainline";
main.Id = mainTargetId;
main.Type = StreamType.Mainline;
main.Parent = new DepotPath("none");
main.Options = new StreamOptionEnum(StreamOption.None);
main.Name = "mainline";
main.Paths = new ViewMap();
MapEntry p1 = new MapEntry(MapType.Import, new DepotPath("..."), null);
main.Paths.Add(p1);
MapEntry p2 = new MapEntry(MapType.Share, new DepotPath("core/gui/..."), null);
main.Paths.Add(p2);
main.OwnerName = "admin";
Stream mainline = rep.CreateStream(main, null);
</code>
To create a new development type stream with the parent //Rocket/mainline:
<code>
Stream dev = new Stream();
string developmentTargetId = "//Rocket/dev";
dev.Id = developmentTargetId;
dev.Type = StreamType.Development;
dev.Parent = new DepotPath("//Rocket/mainline");
dev.Name = "releasetest";
dev.Options = new StreamOptionEnum(StreamOption.None);
dev.Paths = new ViewMap();
MapEntry devp1 = new MapEntry(MapType.Share, new DepotPath("..."), null);
dev.Paths.Add(devp1);
dev.OwnerName = "admin";
Stream dev1 = rep.CreateStream(dev, null);
</code>
</example>
<seealso cref="T:Perforce.P4.StreamCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.CreateStream(Perforce.P4.Stream)">
<summary>
Create a new stream in the repository.
</summary>
<param name="stream">Stream specification for the new stream</param>
<returns>The Stream object if new stream was created, null if creation failed</returns>
<example>
To create a new locked release type stream in the repository, with ignored and remapped
paths:
<code>
Stream s = new Stream();
string targetId = "//Rocket/rel1";
s.Id = targetId;
s.Type = StreamType.Release;
s.Options = new StreamOptionEnum(StreamOption.Locked | StreamOption.NoToParent);
s.Parent = new DepotPath("//Rocket/main");
s.Name = "Release1";
s.Paths = new ViewMap();
MapEntry p1 = new MapEntry(MapType.Import, new DepotPath("..."), null);
s.Paths.Add(p1);
MapEntry p2 = new MapEntry(MapType.Share, new DepotPath("core/gui/..."), null);
s.Paths.Add(p2);
s.OwnerName = "admin";
s.Description = "release stream for first release";
s.Ignored = new ViewMap();
MapEntry ig1 = new MapEntry(MapType.Include, new DepotPath(".tmp"), null);
s.Ignored.Add(ig1);
MapEntry ig2 = new MapEntry(MapType.Include, new DepotPath("/bmps/..."), null);
s.Ignored.Add(ig2);
MapEntry ig3 = new MapEntry(MapType.Include, new DepotPath("/test"), null);
s.Ignored.Add(ig3);
MapEntry ig4 = new MapEntry(MapType.Include, new DepotPath(".jpg"), null);
s.Ignored.Add(ig4);
s.Remapped = new ViewMap();
MapEntry re1 = new MapEntry(MapType.Include, new DepotPath("..."), new DepotPath("x/..."));
s.Remapped.Add(re1);
MapEntry re2 = new MapEntry(MapType.Include, new DepotPath("y/*"), new DepotPath("y/z/*"));
s.Remapped.Add(re2);
MapEntry re3 = new MapEntry(MapType.Include, new DepotPath("ab/..."), new DepotPath("a/..."));
s.Remapped.Add(re3);
Stream newStream = rep.CreateStream(s);
</code>
</example>
</member>
<member name="M:Perforce.P4.Repository.UpdateStream(Perforce.P4.Stream)">
<summary>
Update the record for a stream in the repository
</summary>
<param name="stream">Stream specification for the stream being updated</param>
<returns>The Stream object if new stream was saved, null if creation failed</returns>
<example>
To set the locked option on a stream:
<code>
Stream streamToUpdate = rep.GetStream("//Rocket/GUI");
streamToUpdate.Options |= StreamOption.Locked;
streamToUpdate = rep.UpdateStream(streamToUpdate);
</code>
</example>
</member>
<member name="M:Perforce.P4.Repository.UpdateStream(Perforce.P4.Stream,Perforce.P4.Options)">
<summary>
Update the record for a stream in the repository
</summary>
<param name="stream">Stream specification for the stream being updated</param>
<returns>The Stream object if new stream was saved, null if creation failed</returns>
<example>
To update a locked stream when connected as an admin user:
<code>
Stream streamToUpdate = rep.GetStream("//Rocket/GUI");
// set locked option
streamToUpdate.Options |= StreamOption.Locked;
streamToUpdate = rep.UpdateStream(streamToUpdate);
streamToUpdate.Description = "edited";
string parent = streamToUpdate.Parent.ToString();
string type = streamToUpdate.Type.ToString();
streamToUpdate = rep.UpdateStream(streamToUpdate,
new StreamCmdOptions(StreamCmdFlags.Force, parent, type ));
</code>
</example>
</member>
<member name="M:Perforce.P4.Repository.GetStream(System.String,System.String,Perforce.P4.Options)">
<summary>
Get the record for an existing stream from the repository.
</summary>
<param name="stream">Stream name</param>
<param name="options">There are no valid flags to use when fetching an existing stream</param>
<returns>The Stream object if new stream was found, null if creation failed</returns>
<example>
Get the stream with the stream Id "//Rocket/GUI":
<code>
string targetStream = "//Rocket/GUI";
Stream s = rep.GetStream(targetStream, null, null);
</code>
Get stream spec for a new development type stream with the parent
//Rocket/MAIN:
<code>
string targetStream = "//Rocket/GUI2";
string parentStream = "//Rocket/MAIN";
Stream stream = rep.GetStream(targetStream, parentStream,
new StreamCmdOptions(StreamCmdFlags.None, parentStream,
StreamType.Development.ToString()));
</code>
</example>
</member>
<member name="M:Perforce.P4.Repository.GetStream(System.String)">
<summary>
Get the record for an existing stream from the repository.
</summary>
<param name="stream">Stream name</param>
<returns>The Stream object if new stream was found, null if creation failed</returns>
<example>
Get the stream with the stream Id "//Rocket/GUI":
<code>
string targetStream = "//Rocket/GUI";
Stream s = rep.GetStream(targetStream);
</code>
</example>
</member>
<!-- Badly formed XML comment ignored for member "M:Perforce.P4.Repository.GetStreams(Perforce.P4.Options,Perforce.P4.FileSpec[])" -->
<member name="M:Perforce.P4.Repository.DeleteStream(Perforce.P4.Stream,Perforce.P4.Options)">
<summary>
Delete a stream from the repository
</summary>
<param name="stream">The stream to be deleted</param>
<param name="options">Only the '-f' flag is valid when deleting an existing stream</param>
<example>
To delete a locked stream with no child streams or active clients as an admin user:
<code>
Stream stream = rep.GetStream("//Rocket/GUI");
StreamCmdOptions opts = new StreamCmdOptions(StreamCmdFlags.Force,
null, null);
rep.DeleteStream(stream, opts);
</code>
</example>
</member>
<member name="M:Perforce.P4.Repository.GetStreamMetaData(Perforce.P4.Stream,Perforce.P4.Options)">
<summary>
Get the integration status for a stream in the repository
</summary>
<param name="stream">The stream to get integration status on</param>
<param name="options">options for the istat command</param>
<returns>The integration status of the stream</returns>
<remarks>
<br/><b>p4 help istat</b>
<br/>
<br/> istat -- Show/cache a stream's integration status
<br/>
<br/> p4 istat [ -a -c -r -s ] stream
<br/>
<br/> 'p4 istat' shows a stream's cached integration status with respect
<br/> to its parent. If the cache is stale, either because newer changes
<br/> have been submitted or the stream's branch view has changed, 'p4
<br/> istat' checks for pending integrations and updates the cache before
<br/> showing status.
<br/>
<br/> Pending integrations are shown only if they are expected by the
<br/> stream; that is, only if they are warranted by the stream's type
<br/> and its fromParent/toParent flow options. (See 'p4 help stream'.)
<br/>
<br/> The -r flag shows the status of integration to the stream from its
<br/> parent. By default, status of integration in the other direction is
<br/> shown, from the stream to its parent.
<br/>
<br/> The -a flag shows status of integration in both directions.
<br/>
<br/> The -c flag forces 'p4 istat' to assume the cache is stale; it
<br/> causes a search for pending integrations. Use of this flag can
<br/> impact server performance.
<br/>
<br/> The -s flag shows cached state without refreshing stale data.
<br/>
<br/>
</remarks>
<example>
Get the direction of integration for stream "//Rocket/GUI" with respect
to its parent:
<code>
Stream s = rep.GetStream("//Rocket/GUI",null,null);
StreamMetaData smd = rep.GetStreamMetaData(s, null);
StreamMetaData.IntegAction action = smd.IntegToParentHow;
</code>
Get the direction of integration for stream "//Rocket/GUI" from its parent:
<code>
Stream s = rep.GetStream("//Rocket/GUI",null,null);
StreamMetaData smd = rep.GetStreamMetaData(s,new Options(GetStreamMetaDataCmdFlags.Reverse));
StreamMetaData.IntegAction action = smd.IntegFromParentHow;
</code>
</example>
</member>
<member name="M:Perforce.P4.Repository.CreateUser(Perforce.P4.User,Perforce.P4.Options)">
<summary>
Create a new user in the repository.
</summary>
<param name="user">User specification for the new user</param>
<param name="options">The '-f' and '-i' flags are required when creating a new user</param>
<returns>The User object if new user was created, null if creation failed</returns>
<remarks> The '-i' flag is added if not specified by the caller
<br/>
<br/><b>p4 help user</b>
<br/>
<br/> user -- Create or edit a user specification
<br/>
<br/> p4 user [-f] [name]
<br/> p4 user -d [-f] name
<br/> p4 user -o [name]
<br/> p4 user -i [-f]
<br/>
<br/> Create a new user specification or edit an existing user specification.
<br/> The specification form is put into a temporary file and the editor
<br/> (configured by the environment variable $P4EDITOR) is invoked.
<br/>
<br/> Normally, a user specification is created automatically the first
<br/> time that the user issues any command that updates the depot. The
<br/> 'p4 user' command is typically used to edit the user's subscription
<br/> list for change review.
<br/>
<br/> The user specification form contains the following fields:
<br/>
<br/> User: The user name (read-only).
<br/>
<br/> Email: The user's email address (Default: user@client).
<br/>
<br/> Update: The date the specification was last modified (read-only).
<br/>
<br/> Access: The date that the user last issued a client command.
<br/>
<br/> FullName: The user's real name.
<br/>
<br/> JobView: Selects jobs that are displayed when the user creates
<br/> a changelist. These jobs can be closed automatically
<br/> when the user submits the changelist. For a description
<br/> of jobview syntax, see 'p4 help jobview'
<br/>
<br/> Reviews: The subscription list for change review. There is no
<br/> limit on the number of lines that this field can contain.
<br/> You can include the following wildcards:
<br/>
<br/> ... matches any characters including /
<br/> * matches any character except /
<br/>
<br/> Password: The user's password. See 'p4 help passwd'.
<br/>
<br/> Type: Must be 'service', operator, or 'standard'. Default is
<br/> 'standard'. Once set, the user type cannot be changed.
<br/>
<br/> AuthMethod: Must be 'perforce' or 'ldap'. Default is 'perforce'
<br/> Unless overridden by the 'auth.default.method'
<br/> configurable, see 'p4 help configurables'. AuthMethod
<br/> can only be changed when the -f flag has been provided.
<br/>
<br/> The -d flag deletes the specified user (unless the user has files
<br/> open).
<br/>
<br/> The -o flag writes the user specification to the standard output.
<br/> The user's editor is not invoked.
<br/>
<br/> The -i flag reads a user specification from the standard input.
<br/> The user's editor is not invoked.
<br/>
<br/> The -f flag forces the creation, update or deletion of the specified
<br/> user, and enables you to change the Last Modified date. By default,
<br/> users can only delete or modify their own user specifications. The
<br/> -f flag requires 'super' access, which is granted by 'p4 protect'.
<br/>
<br/>
</remarks>
<example>
To create a user with the username bsmith (when connected with
Connection.UserName = "bsmith"):
<code>
User u = new User();
u.Id = "bsmith";
u.FullName = "Brian Smith";
u.EmailAddress = "bsmith@hotmail.com";
u = Repository.CreateUser(u, null);
</code>
To create a user with the username bsmith (when connected with
a user that has super access):
<code>
User u = new User();
u.Id = "bsmith";
u.FullName = "Brian Smith";
u.EmailAddress = "bsmith@hotmail.com";
UserCmdOptions opts = new UserCmdOptions(UserCmdFlags.Force);
u = Repository.CreateUser(u, opts);
</code>
</example>
<seealso cref="T:Perforce.P4.UserCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.CreateUser(Perforce.P4.User)">
<summary>
Create a new user in the repository.
</summary>
<param name="user">User specification for the new user</param>
<returns>The User object if new user was created, null if creation failed</returns>
<remarks> The '-i' flag is added if not specified by the caller
<br/>
<br/><b>p4 help user</b>
<br/>
<br/> user -- Create or edit a user specification
<br/>
<br/> p4 user [-f] [name]
<br/> p4 user -d [-f] name
<br/> p4 user -o [name]
<br/> p4 user -i [-f]
<br/>
<br/> Create a new user specification or edit an existing user specification.
<br/> The specification form is put into a temporary file and the editor
<br/> (configured by the environment variable $P4EDITOR) is invoked.
<br/>
<br/> Normally, a user specification is created automatically the first
<br/> time that the user issues any command that updates the depot. The
<br/> 'p4 user' command is typically used to edit the user's subscription
<br/> list for change review.
<br/>
<br/> The user specification form contains the following fields:
<br/>
<br/> User: The user name (read-only).
<br/>
<br/> Email: The user's email address (Default: user@client).
<br/>
<br/> Update: The date the specification was last modified (read-only).
<br/>
<br/> Access: The date that the user last issued a client command.
<br/>
<br/> FullName: The user's real name.
<br/>
<br/> JobView: Selects jobs that are displayed when the user creates
<br/> a changelist. These jobs can be closed automatically
<br/> when the user submits the changelist. For a description
<br/> of jobview syntax, see 'p4 help jobview'
<br/>
<br/> Reviews: The subscription list for change review. There is no
<br/> limit on the number of lines that this field can contain.
<br/> You can include the following wildcards:
<br/>
<br/> ... matches any characters including /
<br/> * matches any character except /
<br/>
<br/> Password: The user's password. See 'p4 help passwd'.
<br/>
<br/> Type: Must be 'service', operator, or 'standard'. Default is
<br/> 'standard'. Once set, the user type cannot be changed.
<br/>
<br/> AuthMethod: Must be 'perforce' or 'ldap'. Default is 'perforce'
<br/> Unless overridden by the 'auth.default.method'
<br/> configurable, see 'p4 help configurables'. AuthMethod
<br/> can only be changed when the -f flag has been provided.
<br/>
<br/> The -d flag deletes the specified user (unless the user has files
<br/> open).
<br/>
<br/> The -o flag writes the user specification to the standard output.
<br/> The user's editor is not invoked.
<br/>
<br/> The -i flag reads a user specification from the standard input.
<br/> The user's editor is not invoked.
<br/>
<br/> The -f flag forces the creation, update or deletion of the specified
<br/> user, and enables you to change the Last Modified date. By default,
<br/> users can only delete or modify their own user specifications. The
<br/> -f flag requires 'super' access, which is granted by 'p4 protect'.
<br/>
<br/>
</remarks>
<example>
To create a user with the username bsmith (when connected with
Connection.UserName = "bsmith"):
<code>
User u = new User();
u.Id = "bsmith";
u.FullName = "Brian Smith";
u.EmailAddress = "bsmith@hotmail.com";
u = Repository.CreateUser(u);
</code>
</example>
<seealso cref="T:Perforce.P4.UserCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.UpdateUser(Perforce.P4.User)">
<summary>
Update the record for a user in the repository
</summary>
<param name="user">User specification for the user being updated</param>
<returns>The User object if new user was saved, null if creation failed</returns>
<remarks> The '-i' flag is added if not specified by the caller
<br/>
<br/><b>p4 help user</b>
<br/>
<br/> user -- Create or edit a user specification
<br/>
<br/> p4 user [-f] [name]
<br/> p4 user -d [-f] name
<br/> p4 user -o [name]
<br/> p4 user -i [-f]
<br/>
<br/> Create a new user specification or edit an existing user specification.
<br/> The specification form is put into a temporary file and the editor
<br/> (configured by the environment variable $P4EDITOR) is invoked.
<br/>
<br/> Normally, a user specification is created automatically the first
<br/> time that the user issues any command that updates the depot. The
<br/> 'p4 user' command is typically used to edit the user's subscription
<br/> list for change review.
<br/>
<br/> The user specification form contains the following fields:
<br/>
<br/> User: The user name (read-only).
<br/>
<br/> Email: The user's email address (Default: user@client).
<br/>
<br/> Update: The date the specification was last modified (read-only).
<br/>
<br/> Access: The date that the user last issued a client command.
<br/>
<br/> FullName: The user's real name.
<br/>
<br/> JobView: Selects jobs that are displayed when the user creates
<br/> a changelist. These jobs can be closed automatically
<br/> when the user submits the changelist. For a description
<br/> of jobview syntax, see 'p4 help jobview'
<br/>
<br/> Reviews: The subscription list for change review. There is no
<br/> limit on the number of lines that this field can contain.
<br/> You can include the following wildcards:
<br/>
<br/> ... matches any characters including /
<br/> * matches any character except /
<br/>
<br/> Password: The user's password. See 'p4 help passwd'.
<br/>
<br/> Type: Must be 'service', operator, or 'standard'. Default is
<br/> 'standard'. Once set, the user type cannot be changed.
<br/>
<br/> AuthMethod: Must be 'perforce' or 'ldap'. Default is 'perforce'
<br/> Unless overridden by the 'auth.default.method'
<br/> configurable, see 'p4 help configurables'. AuthMethod
<br/> can only be changed when the -f flag has been provided.
<br/>
<br/> The -d flag deletes the specified user (unless the user has files
<br/> open).
<br/>
<br/> The -o flag writes the user specification to the standard output.
<br/> The user's editor is not invoked.
<br/>
<br/> The -i flag reads a user specification from the standard input.
<br/> The user's editor is not invoked.
<br/>
<br/> The -f flag forces the creation, update or deletion of the specified
<br/> user, and enables you to change the Last Modified date. By default,
<br/> users can only delete or modify their own user specifications. The
<br/> -f flag requires 'super' access, which is granted by 'p4 protect'.
<br/>
<br/>
</remarks>
<example>
To update a user with the username bsmith (when connected with
Connection.UserName = "bsmith"):
<code>
User u = Repository.GetUser("bsmith");
// update email address
u.EmailAddress = "bsmith@hotmail.com";
u = Repository.UpdateUser(u, null);
</code>
</example>
<seealso cref="T:Perforce.P4.UserCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.UpdateUser(Perforce.P4.User,Perforce.P4.Options)">
<summary>
Update the record for a user in the repository
</summary>
<param name="user">User specification for the user being updated</param>
<returns>The User object if new user was saved, null if creation failed</returns>
<remarks> The '-i' flag is added if not specified by the caller
<br/>
<br/><b>p4 help user</b>
<br/>
<br/> user -- Create or edit a user specification
<br/>
<br/> p4 user [-f] [name]
<br/> p4 user -d [-f] name
<br/> p4 user -o [name]
<br/> p4 user -i [-f]
<br/>
<br/> Create a new user specification or edit an existing user specification.
<br/> The specification form is put into a temporary file and the editor
<br/> (configured by the environment variable $P4EDITOR) is invoked.
<br/>
<br/> Normally, a user specification is created automatically the first
<br/> time that the user issues any command that updates the depot. The
<br/> 'p4 user' command is typically used to edit the user's subscription
<br/> list for change review.
<br/>
<br/> The user specification form contains the following fields:
<br/>
<br/> User: The user name (read-only).
<br/>
<br/> Email: The user's email address (Default: user@client).
<br/>
<br/> Update: The date the specification was last modified (read-only).
<br/>
<br/> Access: The date that the user last issued a client command.
<br/>
<br/> FullName: The user's real name.
<br/>
<br/> JobView: Selects jobs that are displayed when the user creates
<br/> a changelist. These jobs can be closed automatically
<br/> when the user submits the changelist. For a description
<br/> of jobview syntax, see 'p4 help jobview'
<br/>
<br/> Reviews: The subscription list for change review. There is no
<br/> limit on the number of lines that this field can contain.
<br/> You can include the following wildcards:
<br/>
<br/> ... matches any characters including /
<br/> * matches any character except /
<br/>
<br/> Password: The user's password. See 'p4 help passwd'.
<br/>
<br/> Type: Must be 'service', operator, or 'standard'. Default is
<br/> 'standard'. Once set, the user type cannot be changed.
<br/>
<br/> AuthMethod: Must be 'perforce' or 'ldap'. Default is 'perforce'
<br/> Unless overridden by the 'auth.default.method'
<br/> configurable, see 'p4 help configurables'. AuthMethod
<br/> can only be changed when the -f flag has been provided.
<br/>
<br/> The -d flag deletes the specified user (unless the user has files
<br/> open).
<br/>
<br/> The -o flag writes the user specification to the standard output.
<br/> The user's editor is not invoked.
<br/>
<br/> The -i flag reads a user specification from the standard input.
<br/> The user's editor is not invoked.
<br/>
<br/> The -f flag forces the creation, update or deletion of the specified
<br/> user, and enables you to change the Last Modified date. By default,
<br/> users can only delete or modify their own user specifications. The
<br/> -f flag requires 'super' access, which is granted by 'p4 protect'.
<br/>
<br/>
</remarks>
<example>
To update a user with the username bsmith (when connected with
a user that has super access):
<code>
User u = Repository.GetUser("bsmith");
// update email address
u.EmailAddress = "bsmith@hotmail.com";
UserCmdOptions opts = new UserCmdOptions(UserCmdFlags.Force);
u = Repository.UpdateUser(u, opts);
</code>
</example>
<seealso cref="T:Perforce.P4.UserCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.GetUser(System.String,Perforce.P4.Options)">
<summary>
Get the record for an existing user from the repository.
</summary>
<param name="user">User name</param>
<param name="options">There are no valid flags to use when fetching an existing user</param>
<returns>The User object if new user was found, null if creation failed</returns>
<remarks> The '-i' flag is added if not specified by the caller
<br/>
<br/><b>p4 help user</b>
<br/>
<br/> user -- Create or edit a user specification
<br/>
<br/> p4 user [-f] [name]
<br/> p4 user -d [-f] name
<br/> p4 user -o [name]
<br/> p4 user -i [-f]
<br/>
<br/> Create a new user specification or edit an existing user specification.
<br/> The specification form is put into a temporary file and the editor
<br/> (configured by the environment variable $P4EDITOR) is invoked.
<br/>
<br/> Normally, a user specification is created automatically the first
<br/> time that the user issues any command that updates the depot. The
<br/> 'p4 user' command is typically used to edit the user's subscription
<br/> list for change review.
<br/>
<br/> The user specification form contains the following fields:
<br/>
<br/> User: The user name (read-only).
<br/>
<br/> Email: The user's email address (Default: user@client).
<br/>
<br/> Update: The date the specification was last modified (read-only).
<br/>
<br/> Access: The date that the user last issued a client command.
<br/>
<br/> FullName: The user's real name.
<br/>
<br/> JobView: Selects jobs that are displayed when the user creates
<br/> a changelist. These jobs can be closed automatically
<br/> when the user submits the changelist. For a description
<br/> of jobview syntax, see 'p4 help jobview'
<br/>
<br/> Reviews: The subscription list for change review. There is no
<br/> limit on the number of lines that this field can contain.
<br/> You can include the following wildcards:
<br/>
<br/> ... matches any characters including /
<br/> * matches any character except /
<br/>
<br/> Password: The user's password. See 'p4 help passwd'.
<br/>
<br/> Type: Must be 'service', operator, or 'standard'. Default is
<br/> 'standard'. Once set, the user type cannot be changed.
<br/>
<br/> AuthMethod: Must be 'perforce' or 'ldap'. Default is 'perforce'
<br/> Unless overridden by the 'auth.default.method'
<br/> configurable, see 'p4 help configurables'. AuthMethod
<br/> can only be changed when the -f flag has been provided.
<br/>
<br/> The -d flag deletes the specified user (unless the user has files
<br/> open).
<br/>
<br/> The -o flag writes the user specification to the standard output.
<br/> The user's editor is not invoked.
<br/>
<br/> The -i flag reads a user specification from the standard input.
<br/> The user's editor is not invoked.
<br/>
<br/> The -f flag forces the creation, update or deletion of the specified
<br/> user, and enables you to change the Last Modified date. By default,
<br/> users can only delete or modify their own user specifications. The
<br/> -f flag requires 'super' access, which is granted by 'p4 protect'.
<br/>
<br/>
</remarks>
<example>
To get a user's specification for a user with the username bsmith:
<code>
User u = Repository.GetUser("bsmith", null);
</code>
</example>
<seealso cref="T:Perforce.P4.UserCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.GetUser(System.String)">
<summary>
Get the record for an existing user from the repository.
</summary>
<param name="user">User name</param>
<param name="options">There are no valid flags to use when fetching an existing user</param>
<returns>The User object if new user was found, null if creation failed</returns>
<remarks> The '-i' flag is added if not specified by the caller
<br/>
<br/><b>p4 help user</b>
<br/>
<br/> user -- Create or edit a user specification
<br/>
<br/> p4 user [-f] [name]
<br/> p4 user -d [-f] name
<br/> p4 user -o [name]
<br/> p4 user -i [-f]
<br/>
<br/> Create a new user specification or edit an existing user specification.
<br/> The specification form is put into a temporary file and the editor
<br/> (configured by the environment variable $P4EDITOR) is invoked.
<br/>
<br/> Normally, a user specification is created automatically the first
<br/> time that the user issues any command that updates the depot. The
<br/> 'p4 user' command is typically used to edit the user's subscription
<br/> list for change review.
<br/>
<br/> The user specification form contains the following fields:
<br/>
<br/> User: The user name (read-only).
<br/>
<br/> Email: The user's email address (Default: user@client).
<br/>
<br/> Update: The date the specification was last modified (read-only).
<br/>
<br/> Access: The date that the user last issued a client command.
<br/>
<br/> FullName: The user's real name.
<br/>
<br/> JobView: Selects jobs that are displayed when the user creates
<br/> a changelist. These jobs can be closed automatically
<br/> when the user submits the changelist. For a description
<br/> of jobview syntax, see 'p4 help jobview'
<br/>
<br/> Reviews: The subscription list for change review. There is no
<br/> limit on the number of lines that this field can contain.
<br/> You can include the following wildcards:
<br/>
<br/> ... matches any characters including /
<br/> * matches any character except /
<br/>
<br/> Password: The user's password. See 'p4 help passwd'.
<br/>
<br/> Type: Must be 'service', operator, or 'standard'. Default is
<br/> 'standard'. Once set, the user type cannot be changed.
<br/>
<br/> AuthMethod: Must be 'perforce' or 'ldap'. Default is 'perforce'
<br/> Unless overridden by the 'auth.default.method'
<br/> configurable, see 'p4 help configurables'. AuthMethod
<br/> can only be changed when the -f flag has been provided.
<br/>
<br/> The -d flag deletes the specified user (unless the user has files
<br/> open).
<br/>
<br/> The -o flag writes the user specification to the standard output.
<br/> The user's editor is not invoked.
<br/>
<br/> The -i flag reads a user specification from the standard input.
<br/> The user's editor is not invoked.
<br/>
<br/> The -f flag forces the creation, update or deletion of the specified
<br/> user, and enables you to change the Last Modified date. By default,
<br/> users can only delete or modify their own user specifications. The
<br/> -f flag requires 'super' access, which is granted by 'p4 protect'.
<br/>
<br/>
</remarks>
<example>
To get a user's specification for a user with the username bsmith:
<code>
User u = Repository.GetUser("bsmith");
</code>
</example>
<seealso cref="T:Perforce.P4.UserCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.GetUsers(Perforce.P4.Options,System.String[])">
<summary>
Get a list of users from the repository
</summary>
<param name="options">Options for the users command. See: <see cref="T:Perforce.P4.UsersCmdFlags"/></param>
<param name="user">Optional list of users. </param>
<returns>A list containing the matching users</returns>
<remarks>
<br/><b>p4 help users</b>
<br/>
<br/> users -- List Perforce users
<br/>
<br/> p4 users [-l -a -r -c] [-m max] [user ...]
<br/>
<br/> Lists all Perforce users or users that match the 'user' argument.
<br/> The report includes the last time that each user accessed the system.
<br/>
<br/> The -m max flag limits output to the first 'max' number of users.
<br/>
<br/> The -a flag includes service and operator users in the output.
<br/>
<br/> The -l flag includes additional information in the output. The -l
<br/> flag requires 'super' access, which is granted by 'p4 protect'.
<br/>
<br/> The -r and -c flags are only allowed on replica servers. When
<br/> -r is given only users who have used a replica are reported and
<br/> when -c is given only the user information from the central server
<br/> is reported. Otherwise on a replica server, the user list will
<br/> be slightly different from the master server as the user access times
<br/> will reflect replica usage or master usage whichever is newer.
<br/>
<br/>
</remarks>
<example>
To get the first 10 users that start with the letter 'A':
<code>
UsersCmdOptions opts = new UsersCmdOptions(UsersCmdFlags.None, 10);
IList<User> users = Repository.getUsers(opts, "A*");
</code>
To get the users for 'Bob', 'Ted', 'Carol' and 'Alice':
<code>
UsersCmdOptions opts = new UsersCmdOptions(UsersCmdFlags.None, -1);
IList<User> users = Repository.getUsers(opts, "Bob", "Ted", "Carol", "Alice");
</code>
To get all the users (WARNING, will fetch all users from the repository):
<code>
UsersCmdOptions opts = new UsersCmdOptions(UsersCmdFlags.IncludeAll, -1);
IList<User> users = Repository.getUsers(opts, null);
</code>
</example>
<seealso cref="T:Perforce.P4.UsersCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.GetUsers(System.Collections.Generic.IList{System.String},Perforce.P4.Options)">
<summary>
Get a list of users from the repository
</summary>
<param name="options">Options for the users command. See: <see cref="T:Perforce.P4.UsersCmdFlags"/></param>
<param name="user">Optional list of users. </param>
<returns>A list containing the matching users</returns>
<remarks>
<br/><b>p4 help users</b>
<br/>
<br/> users -- List Perforce users
<br/>
<br/> p4 users [-l -a -r -c] [-m max] [user ...]
<br/>
<br/> Lists all Perforce users or users that match the 'user' argument.
<br/> The report includes the last time that each user accessed the system.
<br/>
<br/> The -m max flag limits output to the first 'max' number of users.
<br/>
<br/> The -a flag includes service and operator users in the output.
<br/>
<br/> The -l flag includes additional information in the output. The -l
<br/> flag requires 'super' access, which is granted by 'p4 protect'.
<br/>
<br/> The -r and -c flags are only allowed on replica servers. When
<br/> -r is given only users who have used a replica are reported and
<br/> when -c is given only the user information from the central server
<br/> is reported. Otherwise on a replica server, the user list will
<br/> be slightly different from the master server as the user access times
<br/> will reflect replica usage or master usage whichever is newer.
<br/>
<br/>
</remarks>
<example>
To get the first 10 users that start with the letter 'A':
<code>
UsersCmdOptions opts = new UsersCmdOptions(UsersCmdFlags.None, 10);
IList<String> names = new List<String>();
names.Add("A*");
IList<User> users = Repository.getUsers(names, opts);
</code>
To get the users for 'Bob', 'Ted', 'Carol' and 'Alice':
<code>
UsersCmdOptions opts = new UsersCmdOptions(UsersCmdFlags.None, -1);
IList<String> names = new List<String>();
names.Add("Bob");
names.Add("Ted");
names.Add("Carol");
names.Add("Alice");
IList<User> users = Repository.getUsers(names, opts);
</code>
To get all the users (WARNING, will fetch all users from the repository):
<code>
UsersCmdOptions opts = new UsersCmdOptions(UsersCmdFlags.IncludeAll, -1);
IList<User> users = Repository.getUsers(null, opts);
</code>
</example>
<seealso cref="T:Perforce.P4.UsersCmdFlags"/>
</member>
<member name="M:Perforce.P4.Repository.DeleteUser(Perforce.P4.User,Perforce.P4.Options)">
<summary>
Delete a user from the repository
</summary>
<param name="user">The user to be deleted</param>
<param name="options">Only the '-f' flag is valid when deleting an existing user</param>
<remarks>
<br/>
<br/><b>p4 help user</b>
<br/>
<br/> user -- Create or edit a user specification
<br/>
<br/> p4 user [-f] [name]
<br/> p4 user -d [-f] name
<br/> p4 user -o [name]
<br/> p4 user -i [-f]
<br/>
<br/> Create a new user specification or edit an existing user specification.
<br/> The specification form is put into a temporary file and the editor
<br/> (configured by the environment variable $P4EDITOR) is invoked.
<br/>
<br/> Normally, a user specification is created automatically the first
<br/> time that the user issues any command that updates the depot. The
<br/> 'p4 user' command is typically used to edit the user's subscription
<br/> list for change review.
<br/>
<br/> The user specification form contains the following fields:
<br/>
<br/> User: The user name (read-only).
<br/>
<br/> Email: The user's email address (Default: user@client).
<br/>
<br/> Update: The date the specification was last modified (read-only).
<br/>
<br/> Access: The date that the user last issued a client command.
<br/>
<br/> FullName: The user's real name.
<br/>
<br/> JobView: Selects jobs that are displayed when the user creates
<br/> a changelist. These jobs can be closed automatically
<br/> when the user submits the changelist. For a description
<br/> of jobview syntax, see 'p4 help jobview'
<br/>
<br/> Reviews: The subscription list for change review. There is no
<br/> limit on the number of lines that this field can contain.
<br/> You can include the following wildcards:
<br/>
<br/> ... matches any characters including /
<br/> * matches any character except /
<br/>
<br/> Password: The user's password. See 'p4 help passwd'.
<br/>
<br/> Type: Must be 'service', operator, or 'standard'. Default is
<br/> 'standard'. Once set, the user type cannot be changed.
<br/>
<br/> AuthMethod: Must be 'perforce' or 'ldap'. Default is 'perforce'
<br/> Unless overridden by the 'auth.default.method'
<br/> configurable, see 'p4 help configurables'. AuthMethod
<br/> can only be changed when the -f flag has been provided.
<br/>
<br/> The -d flag deletes the specified user (unless the user has files
<br/> open).
<br/>
<br/> The -o flag writes the user specification to the standard output.
<br/> The user's editor is not invoked.
<br/>
<br/> The -i flag reads a user specification from the standard input.
<br/> The user's editor is not invoked.
<br/>
<br/> The -f flag forces the creation, update or deletion of the specified
<br/> user, and enables you to change the Last Modified date. By default,
<br/> users can only delete or modify their own user specifications. The
<br/> -f flag requires 'super' access, which is granted by 'p4 protect'.
<br/>
<br/>
</remarks>
<example>
To delete a user with the username bsmith (when connected with
Connection.UserName = "bsmith"):
<code>
User u = Repository.GetUser("bsmith");
Repository.DeleteUser(u, null);
</code>
To delete a user with the username bsmith (when connected with
a user that has super access):
<code>
UserCmdOptions opts = new UserCmdOptions(UserCmdFlags.Force);
User u = Repository.GetUser("bsmith");
Repository.DeleteUser(u, opts);
</code>
</example>
<seealso cref="T:Perforce.P4.UserCmdFlags"/>
</member>
<member name="P:Perforce.P4.Repository.Server">
<summary>
Represents a specific Perforce server.
</summary>
</member>
<member name="P:Perforce.P4.Repository.Connection">
<summary>
Represents the logical connection between a specific Perforce Server
instance and a specific client application.
</summary>
</member>
<member name="T:Perforce.P4.P4CommandResult">
<summary>
Class representing the results of executing a command on a Perforce Server.
</summary>
</member>
<member name="M:Perforce.P4.P4CommandResult.#ctor(Perforce.P4.P4Command,Perforce.P4.StringList)">
<summary>
Create a P4CommandResult by running a command
</summary>
<param name="cmd">Command to run</param>
<param name="flags">Flags for the command</param>
</member>
<member name="M:Perforce.P4.P4CommandResult.#ctor(Perforce.P4.P4Command)">
<summary>
Create a P4CommandResult by running a command
</summary>
<param name="cmd">Command to run</param>
</member>
<member name="P:Perforce.P4.P4CommandResult.Success">
<summary>
Did the command not return any errors?
</summary>
</member>
<member name="P:Perforce.P4.P4CommandResult.InfoOutput">
<summary>
The info results (if any) of the command execution
</summary>
</member>
<member name="P:Perforce.P4.P4CommandResult.ErrorList">
<summary>
The errors (if any) of the command execution
</summary>
</member>
<member name="P:Perforce.P4.P4CommandResult.TextOutput">
<summary>
The text output from the command
</summary>
</member>
<member name="P:Perforce.P4.P4CommandResult.TaggedOutput">
<summary>
The tagged output of the command
</summary>
</member>
<member name="P:Perforce.P4.P4CommandResult.BinaryOutput">
<summary>
The binary output of the command
</summary>
</member>
<member name="P:Perforce.P4.P4CommandResult.Cmd">
<summary>
The command that was run
</summary>
</member>
<member name="P:Perforce.P4.P4CommandResult.CmdArgs">
<summary>
The arguments for command that was run
</summary>
</member>
<member name="P:Perforce.P4.P4CommandResult.TimeStamp">
<summary>
The time the command completed and the results were collected.
</summary>
</member>
<member name="T:Perforce.P4.BranchSpec">
<summary>
A branch view specification in a Perforce repository.
</summary>
</member>
<member name="M:Perforce.P4.BranchSpec.#ctor">
<summary>
A branch view specification in a Perforce repository.
</summary>
</member>
<member name="M:Perforce.P4.BranchSpec.#ctor(System.String,System.String,System.DateTime,System.DateTime,System.String,System.Boolean,Perforce.P4.ViewMap,Perforce.P4.FormSpec,System.String)">
<summary>
A branch view specification in a Perforce repository.
</summary>
<param name="accessed">The date of the last command used with this spec.</param>
<param name="description">A description of the branch spec (optional).</param>
<param name="id">The branch spec name (read only).</param>
<param name="locked">When true, permits only the owner to change the spec.</param>
<param name="options">Flags to change the branch spec behavior.</param>
<param name="owner">The user who created this branch spec.</param>
<param name="spec">Specifies structural and semantic metadata for form types.</param>
<param name="updated">The date this branch spec was last modified.</param>
<param name="viewmap">Lines mapping of one view of depot files to another.</param>
</member>
<member name="M:Perforce.P4.BranchSpec.FromBranchSpecCmdTaggedOutput(Perforce.P4.TaggedObject)">
<summary>
Read the fields from the tagged output of a branch command
</summary>
<param name="objectInfo">Tagged output from the 'branch' command</param>
</member>
<member name="M:Perforce.P4.BranchSpec.Parse(System.String)">
<summary>
Parse the fields from a branch specification
</summary>
<param name="spec">Text of the branch specification in server format</param>
<returns></returns>
</member>
<member name="F:Perforce.P4.BranchSpec.BranchSpecFormat">
<summary>
Format of a branch specification used to save a branch to the server
</summary>
</member>
<member name="M:Perforce.P4.BranchSpec.ToString">
<summary>
Convert to specification in server format
</summary>
<returns></returns>
</member>
<member name="M:Perforce.P4.BranchSpec.FromBranchSpecsCmdTaggedOutput(Perforce.P4.TaggedObject,System.String,System.Boolean)">
<summary>
Read the fields from the tagged output of a branches command
</summary>
<param name="objectInfo">Tagged output from the 'branches' command</param>
</member>
<member name="P:Perforce.P4.BranchSpec.Id">
<summary>
The branch spec name (read only).
</summary>
</member>
<member name="P:Perforce.P4.BranchSpec.Owner">
<summary>
The user who created this branch spec. Can be changed.
</summary>
</member>
<member name="P:Perforce.P4.BranchSpec.Updated">
<summary>
The date this branch spec was last modified.
</summary>
</member>
<member name="P:Perforce.P4.BranchSpec.Accessed">
<summary>
The date of the last command used with this spec.
</summary>
</member>
<member name="P:Perforce.P4.BranchSpec.Description">
<summary>
A description of the branch spec (optional).
</summary>
</member>
<member name="P:Perforce.P4.BranchSpec.Locked">
<summary>
When true, permits only the owner to change the spec.
</summary>
</member>
<member name="P:Perforce.P4.BranchSpec.ViewMap">
<summary>
Lines mapping of one view of depot files to another.
</summary>
</member>
<member name="P:Perforce.P4.BranchSpec.Spec">
<summary>
Specifies structural and semantic metadata for form types.
</summary>
</member>
<member name="P:Perforce.P4.BranchSpec.Options">
<summary>
Flags to change the branch spec behavior.
</summary>
</member>
<member name="T:Perforce.P4.ShelvedFile">
<summary>
Shelved file information from a Describe -S command
</summary>
</member>
<member name="T:Perforce.P4.Changelist">
<summary>
A changelist specification in a Perforce repository.
</summary>
</member>
<member name="M:Perforce.P4.Changelist.#ctor">
<summary>
Create a new pending changelist
</summary>
</member>
<member name="M:Perforce.P4.Changelist.#ctor(System.Int32,System.Boolean)">
<summary>
Create a new numbered changelist
</summary>
<param name="id"></param>
<param name="pending"></param>
</member>
<member name="M:Perforce.P4.Changelist.FromChangeCmdTaggedOutput(Perforce.P4.TaggedObject,System.String,System.Boolean)">
<summary>
Fill in the fields for the changelist using the tagged output of a "change' command
</summary>
<param name="objectInfo">The tagged output of a "change' command</param>
</member>
<member name="M:Perforce.P4.Changelist.FromChangeCmdTaggedOutput(Perforce.P4.TaggedObject,System.Boolean,System.String,System.Boolean)">
<summary>
Fill in the fields for the changelist using the tagged output of a "change' command
</summary>
<param name="objectInfo">The tagged output of a "change' command</param>
</member>
<member name="M:Perforce.P4.Changelist.Parse(System.String)">
<summary>
Parse the fields from a changelist specification
</summary>
<param name="spec">Text of the changelist specification in server format</param>
<returns></returns>
</member>
<member name="F:Perforce.P4.Changelist.ChangelistSpecFormat">
<summary>
Format of a user specification used to save a user to the server
</summary>
</member>
<member name="M:Perforce.P4.Changelist.ToString">
<summary>
Convert to specification in server format
</summary>
<returns></returns>
</member>
<member name="M:Perforce.P4.Changelist.ToString(System.Boolean)">
<summary>
Convert to a string for display
</summary>
<param name="includeTime">Include the time as well as the date</param>
<returns></returns>
</member>
<member name="M:Perforce.P4.Changelist.FixJobs(Perforce.P4.Options,Perforce.P4.Job[])">
<summary>
</summary>
<param name="options"></param>
<param name="jobs"></param>
<returns></returns>
<remarks>
<br/><b>p4 help fix</b>
<br/>
<br/> fix -- Mark jobs as being fixed by the specified changelist
<br/>
<br/> p4 fix [-d] [-s status] -c changelist# jobName ...
<br/>
<br/> 'p4 fix' marks each named job as being fixed by the changelist
<br/> number specified with -c. The changelist can be pending or
<br/> submitted and the jobs can be open or closed (fixed by another
<br/> changelist).
<br/>
<br/> If the changelist has already been submitted and the job is still
<br/> open, then 'p4 fix' marks the job closed. If the changelist has not
<br/> been submitted and the job is still open, the job is closed when the
<br/> changelist is submitted. If the job is already closed, it remains
<br/> closed.
<br/>
<br/> The -d flag deletes the specified fixes. This operation does not
<br/> otherwise affect the specified changelist or jobs.
<br/>
<br/> The -s flag uses the specified status instead of the default defined
<br/> in the job specification.
<br/>
<br/> The fix's status is reported by 'p4 fixes', and is related to the
<br/> job's status. Certain commands set the job's status to the fix's
<br/> status for each job associated with the change. When a job is fixed
<br/> by a submitted change, the job's status is set to match the fix
<br/> status. When a job is fixed by a pending change, the job's status
<br/> is set to match the fix status when the change is submitted. If the
<br/> fix's status is 'same', the job's status is left unchanged.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Changelist.FixJobs(System.Collections.Generic.IList{Perforce.P4.Job},Perforce.P4.Options)">
<summary>
</summary>
<param name="jobs"></param>
<param name="options"></param>
<returns></returns>
</member>
<member name="M:Perforce.P4.Changelist.FixJobs(Perforce.P4.Options,System.String[])">
<summary>
</summary>
<param name="options"></param>
<param name="jobs"></param>
<returns></returns>
<remarks>
<br/><b>p4 help fix</b>
<br/>
<br/> fix -- Mark jobs as being fixed by the specified changelist
<br/>
<br/> p4 fix [-d] [-s status] -c changelist# jobName ...
<br/>
<br/> 'p4 fix' marks each named job as being fixed by the changelist
<br/> number specified with -c. The changelist can be pending or
<br/> submitted and the jobs can be open or closed (fixed by another
<br/> changelist).
<br/>
<br/> If the changelist has already been submitted and the job is still
<br/> open, then 'p4 fix' marks the job closed. If the changelist has not
<br/> been submitted and the job is still open, the job is closed when the
<br/> changelist is submitted. If the job is already closed, it remains
<br/> closed.
<br/>
<br/> The -d flag deletes the specified fixes. This operation does not
<br/> otherwise affect the specified changelist or jobs.
<br/>
<br/> The -s flag uses the specified status instead of the default defined
<br/> in the job specification.
<br/>
<br/> The fix's status is reported by 'p4 fixes', and is related to the
<br/> job's status. Certain commands set the job's status to the fix's
<br/> status for each job associated with the change. When a job is fixed
<br/> by a submitted change, the job's status is set to match the fix
<br/> status. When a job is fixed by a pending change, the job's status
<br/> is set to match the fix status when the change is submitted. If the
<br/> fix's status is 'same', the job's status is left unchanged.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Changelist.FixJobs(System.Collections.Generic.IList{System.String},Perforce.P4.Options)">
<summary>
</summary>
<param name="jobs"></param>
<param name="options"></param>
<returns></returns>
</member>
<member name="T:Perforce.P4.ClientOption">
<summary>
Flags to configure the client behavior.
</summary>
</member>
<member name="F:Perforce.P4.ClientOption.None">
<summary>
No options.
</summary>
</member>
<member name="F:Perforce.P4.ClientOption.AllWrite">
<summary>
Leaves all files writable on the client;
by default, only files opened by 'p4 edit'
are writable. If set, files might be clobbered
as a result of ignoring the clobber option.
</summary>
</member>
<member name="F:Perforce.P4.ClientOption.Clobber">
<summary>
Permits 'p4 sync' to overwrite writable
files on the client. noclobber is ignored if
allwrite is set.
</summary>
</member>
<member name="F:Perforce.P4.ClientOption.Compress">
<summary>
Compresses data sent between the client
and server to speed up slow connections.
</summary>
</member>
<member name="F:Perforce.P4.ClientOption.Locked">
<summary>
Allows only the client owner to use or change
the client spec. Prevents the client spec from
being deleted.
</summary>
</member>
<member name="F:Perforce.P4.ClientOption.ModTime">
<summary>
Causes 'p4 sync' and 'p4 submit' to preserve
file modification time, as with files with the
+m type modifier. (See 'p4 help filetypes'.)
With nomodtime, file timestamps are updated by
sync and submit operations.
</summary>
</member>
<member name="F:Perforce.P4.ClientOption.RmDir">
<summary>
Makes 'p4 sync' attempt to delete a workspace
directory when all files in it are removed.
</summary>
</member>
<member name="M:Perforce.P4.ClientOptionEnum.ToString">
<summary>
Convert to a client spec formatted string
</summary>
<returns></returns>
</member>
<member name="M:Perforce.P4.ClientOptionEnum.Parse(System.String)">
<summary>
Parse a client spec formatted string
</summary>
<param name="spec"></param>
</member>
<member name="T:Perforce.P4.SubmitType">
<summary>
Flags to change submit behavior.
</summary>
</member>
<member name="F:Perforce.P4.SubmitType.SubmitUnchanged">
<summary>
All open files are submitted (default).
</summary>
</member>
<member name="F:Perforce.P4.SubmitType.RevertUnchanged">
<summary>
Files that have content or type changes
are submitted. Unchanged files are
reverted.
</summary>
</member>
<member name="F:Perforce.P4.SubmitType.LeaveUnchanged">
<summary>
Files that have content or type changes
are submitted. Unchanged files are moved
to the default changelist.
</summary>
</member>
<member name="T:Perforce.P4.ClientSubmitOptions">
<summary>
Client options that define what to do with files upon submit.
</summary>
</member>
<member name="M:Perforce.P4.ClientSubmitOptions.ToString">
<summary>
Convert to a client spec formatted string
</summary>
<returns></returns>
</member>
<member name="M:Perforce.P4.ClientSubmitOptions.Parse(System.String)">
<summary>
Parse a client spec formatted string
</summary>
<param name="spec"></param>
</member>
<member name="P:Perforce.P4.ClientSubmitOptions.Reopen">
<summary>
Determines if the files is reopened upon submit.
</summary>
</member>
<member name="T:Perforce.P4.LineEnd">
<summary>
Sets line-ending character(s) for client text files.
</summary>
</member>
<member name="F:Perforce.P4.LineEnd.Local">
<summary>
mode that is native to the client (default).
</summary>
</member>
<member name="F:Perforce.P4.LineEnd.Unix">
<summary>
linefeed: UNIX style.
</summary>
</member>
<member name="F:Perforce.P4.LineEnd.Mac">
<summary>
carriage return: Macintosh style.
</summary>
</member>
<member name="F:Perforce.P4.LineEnd.Win">
<summary>
carriage return-linefeed: Windows style.
</summary>
</member>
<member name="F:Perforce.P4.LineEnd.Share">
<summary>
hybrid: writes UNIX style but reads UNIX,
Mac or Windows style.
</summary>
</member>
<member name="T:Perforce.P4.Client">
<summary>
A client specification in a Perforce repository.
</summary>
</member>
<member name="M:Perforce.P4.Client.FromClientsCmdTaggedOutput(Perforce.P4.TaggedObject,System.String,System.Boolean)">
<summary>
Parse the tagged output of a 'clients' command
</summary>
<param name="workspaceInfo"></param>
</member>
<member name="M:Perforce.P4.Client.FromClientCmdTaggedOutput(Perforce.P4.TaggedObject)">
<summary>
Parse the tagged output of a 'client' command
</summary>
<param name="workspaceInfo"></param>
</member>
<member name="M:Perforce.P4.Client.Parse(System.String)">
<summary>
Parse a client spec
</summary>
<param name="spec"></param>
<returns></returns>
</member>
<member name="M:Perforce.P4.Client.FormatDateTime(System.DateTime)">
<summary>
Utility function to format a DateTime in the format expected in a spec
</summary>
<param name="dt"></param>
<returns></returns>
</member>
<member name="M:Perforce.P4.Client.ToString">
<summary>
Format as a client spec
</summary>
<returns></returns>
</member>
<member name="M:Perforce.P4.Client.AddFiles(Perforce.P4.Options,Perforce.P4.FileSpec[])">
<summary>
</summary>
<param name="files"></param>
<param name="options"></param>
<returns></returns>
<remarks>
<br/><b>p4 help add</b>
<br/>
<br/> add -- Open a new file to add it to the depot
<br/>
<br/> p4 add [-c changelist#] [-d -f -I -n] [-t filetype] file ...
<br/>
<br/> Open a file for adding to the depot. If the file exists on the
<br/> client, it is read to determine if it is text or binary. If it does
<br/> not exist, it is assumed to be text. To be added, the file must not
<br/> already reside in the depot, or it must be deleted at the current
<br/> head revision. Files can be deleted and re-added.
<br/>
<br/> A 2012.1 client will ignore files that were to be added, if they
<br/> match an exclusion line specified in a P4IGNORE file.
<br/>
<br/> To associate the open files with a specific pending changelist, use
<br/> the -c flag; if you omit the -c flag, the open files are associated
<br/> with the default changelist. If file is already open, it is moved
<br/> into the specified pending changelist. You cannot reopen a file for
<br/> add unless it is already open for add.
<br/>
<br/> As a shortcut to reverting and re-adding, you can use the -d
<br/> flag to reopen currently-open files for add (downgrade) under
<br/> the following circumstances:
<br/>
<br/> A file that is 'opened for edit' and is synced to the head
<br/> revision, and the head revision has been deleted (or moved).
<br/>
<br/> A file that is 'opened for move/add' can be downgraded to add,
<br/> which is useful when the source of the move has been deleted
<br/> or moved. Typically, under these circumstances, your only
<br/> alternative is to revert. In this case, breaking the move
<br/> connection enables you to preserve any content changes in the
<br/> new file and safely revert the source file (of the move).
<br/>
<br/> To specify file type, use the -t flag. By default, 'p4 add'
<br/> determines file type using the name-to-type mapping table managed
<br/> by 'p4 typemap' and by examining the file's contents and execute
<br/> permission bit. If the file type specified by -t or configured in
<br/> the typemap table is a partial filetype, the resulting modifier is
<br/> applied to the file type that is determined by 'p4 add'. For more
<br/> details, see 'p4 help filetypes'.
<br/>
<br/> To add files with filenames that contain wildcard characters, specify
<br/> the -f flag. Filenames that contain the special characters '@', '#',
<br/> '%' or '*' are reformatted to encode the characters using ASCII
<br/> hexadecimal representation. After the files are added, you must
<br/> refer to them using the reformatted file name, because Perforce
<br/> does not recognize the local filesystem name.
<br/>
<br/> The -I flag informs the client that it should not perform any ignore
<br/> checking configured by P4IGNORE.
<br/>
<br/> The -n flag displays a preview of the specified add operation without
<br/> changing any files or metadata.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Client.DeleteFiles(Perforce.P4.Options,Perforce.P4.FileSpec[])">
<summary>
</summary>
<param name="files"></param>
<param name="options"></param>
<returns></returns>
<remarks>
<br/><b>p4 help delete</b>
<br/>
<br/> delete -- Open an existing file for deletion from the depot
<br/>
<br/> p4 delete [-c changelist#] [-n -v -k] file ...
<br/>
<br/> Opens a depot file for deletion.
<br/> If the file is synced in the client workspace, it is removed. If a
<br/> pending changelist number is specified using with the -c flag, the
<br/> file is opened for delete in that changelist. Otherwise, it is opened
<br/> in the default pending changelist.
<br/>
<br/> Files that are deleted generally do not appear on the have list.
<br/>
<br/> The -n flag displays a preview of the operation without changing any
<br/> files or metadata.
<br/>
<br/> The -k flag performs the delete on the server without modifying
<br/> client files. Use with caution, as an incorrect delete can cause
<br/> discrepancies between the state of the client and the corresponding
<br/> server metadata.
<br/>
<br/> The -v flag enables you to delete files that are not synced to the
<br/> client workspace. The files should be specified using depot syntax;
<br/> since the files are not synced, client syntax or local syntax are
<br/> inappropriate and could introduce ambiguities in the file list.
<br/> Note, though, that if the files ARE synced, 'delete -v' will remove
<br/> the files from the client in addition to opening them for delete.
<br/> The preferred way to delete a set of files without transferring
<br/> them to your machine is: 'sync -k file...', then 'delete -k file...'
<br/>
<br/> 'p4 delete' is not supported for files with propagating attributes
<br/> from an edge server in a distributed environment.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Client.EditFiles(Perforce.P4.Options,Perforce.P4.FileSpec[])">
<summary>
</summary>
<param name="files"></param>
<param name="options"></param>
<returns></returns>
<remarks>
<br/><b>p4 help edit</b>
<br/>
<br/> edit -- Open an existing file for edit
<br/>
<br/> p4 edit [-c changelist#] [-k -n] [-t filetype] file ...
<br/>
<br/> Open an existing file for edit. The server records the fact that
<br/> the current user has opened the file in the current workspace, and
<br/> changes the file permission from read-only to read/write.
<br/>
<br/> If -c changelist# is included, the file opened in the specified
<br/> pending changelist. If changelist number is omitted, the file is
<br/> opened in the 'default' changelist.
<br/>
<br/> If -t filetype is specified, the file is assigned that Perforce
<br/> filetype. Otherwise, the filetype of the previous revision is reused.
<br/> If a partial filetype is specified, it is combined with the current
<br/> filetype.For details, see 'p4 help filetypes'.
<br/> Using a filetype of 'auto' will cause the filetype to be chosen
<br/> as if the file were being added, that is the typemap will be
<br/> considered and the file contents may be examined.
<br/>
<br/> The -n flag previews the operation without changing any files or
<br/> metadata.
<br/>
<br/> The -k flag updates metadata without transferring files to the
<br/> workspace. This option can be used to tell the server that files in
<br/> a client workspace are already editable, even if they are not in the
<br/> client view. Typically this flag is used to correct the Perforce
<br/> server when it is wrong about the state of files in the client
<br/> workspace, but incorrect use of this option can result in inaccurate
<br/> file status information.
<br/>
<br/> 'p4 edit' is not supported for files with propagating attributes
<br/> from an edge server in a distributed environment.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Client.GetSyncedFiles(Perforce.P4.Options,Perforce.P4.FileSpec[])">
<summary>
</summary>
<param name="files"></param>
<param name="options"></param>
<returns></returns>
<remarks>
<br/><b>p4 help have</b>
<br/>
<br/> have -- List the revisions most recently synced to the current workspace
<br/>
<br/> p4 have [file ...]
<br/>
<br/> List revision numbers of the currently-synced files. If file name is
<br/> omitted, list all files synced to this client workspace.
<br/>
<br/> The format is: depot-file#revision - client-file
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Client.IntegrateFiles(Perforce.P4.Options,Perforce.P4.FileSpec[])">
<summary>
</summary>
<param name="files"></param>
<param name="options"></param>
<returns></returns>
<remarks>
<br/><b>p4 help integrate</b>
<br/>
<br/> integrate -- Integrate one set of files into another
<br/>
<br/> p4 integrate [options] fromFile[revRange] toFile
<br/> p4 integrate [options] -b branch [-r] [toFile[revRange] ...]
<br/> p4 integrate [options] -b branch -s fromFile[revRange] [toFile ...]
<br/> p4 integrate [options] -S stream [-r] [-P parent] [file[revRange] ...]
<br/>
<br/> options: -c changelist# -Di -f -h -O<flags> -n -m max -R<flags> -q -v
<br/>
<br/> 'p4 integrate' integrates one set of files (the 'source') into
<br/> another (the 'target').
<br/>
<br/> (See also 'p4 merge' and 'p4 copy', variants of 'p4 integrate' that
<br/> may be easier and more effective for the task at hand.)
<br/>
<br/> Using the client workspace as a staging area, 'p4 integrate' adds and
<br/> deletes target files per changes in the source, and schedules all
<br/> other affected target files to be resolved. Target files outside of
<br/> the current client view are not affected. Source files need not be
<br/> within the client view.
<br/>
<br/> 'p4 resolve' must be used to merge file content, and to resolve
<br/> filename and filetype changes. 'p4 submit' commits integrated files
<br/> to the depot. Unresolved files may not be submitted. Integrations
<br/> can be shelved with 'p4 shelve' and abandoned with 'p4 revert'. The
<br/> commands 'p4 integrated' and 'p4 filelog' display integration history.
<br/>
<br/> When 'p4 integrate' schedules a workspace file to be resolved, it
<br/> leaves it read-only. 'p4 resolve' can operate on a read-only file.
<br/> For other pre-submit changes, 'p4 edit' must be used to make the
<br/> file writable.
<br/>
<br/> Source and target files can be specified either on the 'p4 integrate'
<br/> command line or through a branch view. On the command line, fromFile
<br/> is the source file set and toFile is the target file set. With a
<br/> branch view, one or more toFile arguments can be given to limit the
<br/> scope of the target file set.
<br/>
<br/> revRange is a revision or a revision range that limits the span of
<br/> source history to be probed for unintegrated revisions. revRange
<br/> can be used on fromFile, or on toFile, but not on both. When used on
<br/> toFile, it refers to source revisions, not to target revisions. For
<br/> details about revision specifiers, see 'p4 help revisions'.
<br/>
<br/> The -S flag makes 'p4 integrate' use a generated branch view that maps
<br/> a stream (or its underlying real stream) to its parent. With -r, the
<br/> direction of the mapping is reversed. -P can be used to generate the
<br/> branch view using a parent stream other than the stream's actual
<br/> parent. Note that to submit integrated stream files, the current
<br/> client must be switched to the target stream, or to a virtual child
<br/> stream of the target stream.
<br/>
<br/> The -b flag makes 'p4 integrate' use a user-defined branch view.
<br/> (See 'p4 help branch'.) The source is the left side of the branch view
<br/> and the target is the right side. With -r, the direction is reversed.
<br/>
<br/> The -s flag can be used with -b to cause fromFile to be treated as
<br/> the source, and both sides of the branch view to be treated as the
<br/> target, per the branch view mapping. Optional toFile arguments may
<br/> be given to further restrict the scope of the target file set. The
<br/> -r flag is ignored when -s is used.
<br/>
<br/> Note that 'p4 integrate' automatically adusts source-to-target
<br/> mappings for moved and renamed files. (Adjustment occurs only if
<br/> the 'p4 move' command was used to move/rename files.) The scope of
<br/> source and target file sets must include both the old-named and the
<br/> new-named files for mappings to be adjusted. A filename resolve is
<br/> scheduled for each remapped file to allow the target to be moved to
<br/> match the source.
<br/>
<br/> The -f flag forces integrate to ignore integration history and treat
<br/> all source revisions as unintegrated. It is meant to be used with
<br/> revRange to force reintegration of specific, previously integrated
<br/> revisions.
<br/>
<br/> The -O flags cause more information to be output for each file opened:
<br/>
<br/> -Ob Show the base revision for the merge (if any).
<br/> -Or Show the resolve(s) that are being scheduled.
<br/>
<br/> The -R flags modify the way resolves are scheduled:
<br/>
<br/> -Rb Schedules 'branch resolves' instead of branching new
<br/> target files automatically.
<br/>
<br/> -Rd Schedules 'delete resolves' instead of deleting
<br/> target files automatically.
<br/>
<br/> -Rs Skips cherry-picked revisions already integrated.
<br/> This can improve merge results, but can also cause
<br/> multiple resolves per file to be scheduled.
<br/>
<br/> The -Di flag modifies the way deleted revisions are treated. If the
<br/> source file has been deleted and re-added, revisions that precede
<br/> the deletion will be considered to be part of the same source file.
<br/> By default, re-added files are considered to be unrelated to the
<br/> files of the same name that preceded them.
<br/>
<br/> The -h flag leaves the target files at the revision currently synced
<br/> to the client (the '#have' revision). By default, target files are
<br/> automatically synced to the head revision by 'p4 integrate'.
<br/>
<br/> The -m flag limits integration to the first 'max' number of files.
<br/>
<br/> The -n flag displays a preview of integration, without actually
<br/> doing anything.
<br/>
<br/> The -q flag suppresses normal output messages. Messages regarding
<br/> errors or exceptional conditions are displayed.
<br/>
<br/> If -c changelist# is specified, the files are opened in the
<br/> designated numbered pending changelist instead of the 'default'
<br/> changelist.
<br/>
<br/> The -v flag causes a 'virtual' integration that does not modify
<br/> client workspace files unless target files need to be resolved.
<br/> After submitting a virtual integration, 'p4 sync' can be used to
<br/> update the workspace.
<br/>
<br/> Integration is not supported for files with propagating attributes
<br/> from an edge server in a distributed environment. Depending on the
<br/> integration action, target, and source, either the integration or
<br/> resolve command will fail.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Client.IntegrateFiles(Perforce.P4.FileSpec,Perforce.P4.Options,Perforce.P4.FileSpec[])">
<summary>
</summary>
<param name="fromFile"></param>
<param name="toFiles"></param>
<param name="options"></param>
<returns></returns>
<remarks>
<br/><b>p4 help integrate</b>
<br/>
<br/> integrate -- Integrate one set of files into another
<br/>
<br/> p4 integrate [options] fromFile[revRange] toFile
<br/> p4 integrate [options] -b branch [-r] [toFile[revRange] ...]
<br/> p4 integrate [options] -b branch -s fromFile[revRange] [toFile ...]
<br/> p4 integrate [options] -S stream [-r] [-P parent] [file[revRange] ...]
<br/>
<br/> options: -c changelist# -Di -f -h -O<flags> -n -m max -R<flags> -q -v
<br/>
<br/> 'p4 integrate' integrates one set of files (the 'source') into
<br/> another (the 'target').
<br/>
<br/> (See also 'p4 merge' and 'p4 copy', variants of 'p4 integrate' that
<br/> may be easier and more effective for the task at hand.)
<br/>
<br/> Using the client workspace as a staging area, 'p4 integrate' adds and
<br/> deletes target files per changes in the source, and schedules all
<br/> other affected target files to be resolved. Target files outside of
<br/> the current client view are not affected. Source files need not be
<br/> within the client view.
<br/>
<br/> 'p4 resolve' must be used to merge file content, and to resolve
<br/> filename and filetype changes. 'p4 submit' commits integrated files
<br/> to the depot. Unresolved files may not be submitted. Integrations
<br/> can be shelved with 'p4 shelve' and abandoned with 'p4 revert'. The
<br/> commands 'p4 integrated' and 'p4 filelog' display integration history.
<br/>
<br/> When 'p4 integrate' schedules a workspace file to be resolved, it
<br/> leaves it read-only. 'p4 resolve' can operate on a read-only file.
<br/> For other pre-submit changes, 'p4 edit' must be used to make the
<br/> file writable.
<br/>
<br/> Source and target files can be specified either on the 'p4 integrate'
<br/> command line or through a branch view. On the command line, fromFile
<br/> is the source file set and toFile is the target file set. With a
<br/> branch view, one or more toFile arguments can be given to limit the
<br/> scope of the target file set.
<br/>
<br/> revRange is a revision or a revision range that limits the span of
<br/> source history to be probed for unintegrated revisions. revRange
<br/> can be used on fromFile, or on toFile, but not on both. When used on
<br/> toFile, it refers to source revisions, not to target revisions. For
<br/> details about revision specifiers, see 'p4 help revisions'.
<br/>
<br/> The -S flag makes 'p4 integrate' use a generated branch view that maps
<br/> a stream (or its underlying real stream) to its parent. With -r, the
<br/> direction of the mapping is reversed. -P can be used to generate the
<br/> branch view using a parent stream other than the stream's actual
<br/> parent. Note that to submit integrated stream files, the current
<br/> client must be switched to the target stream, or to a virtual child
<br/> stream of the target stream.
<br/>
<br/> The -b flag makes 'p4 integrate' use a user-defined branch view.
<br/> (See 'p4 help branch'.) The source is the left side of the branch view
<br/> and the target is the right side. With -r, the direction is reversed.
<br/>
<br/> The -s flag can be used with -b to cause fromFile to be treated as
<br/> the source, and both sides of the branch view to be treated as the
<br/> target, per the branch view mapping. Optional toFile arguments may
<br/> be given to further restrict the scope of the target file set. The
<br/> -r flag is ignored when -s is used.
<br/>
<br/> Note that 'p4 integrate' automatically adusts source-to-target
<br/> mappings for moved and renamed files. (Adjustment occurs only if
<br/> the 'p4 move' command was used to move/rename files.) The scope of
<br/> source and target file sets must include both the old-named and the
<br/> new-named files for mappings to be adjusted. A filename resolve is
<br/> scheduled for each remapped file to allow the target to be moved to
<br/> match the source.
<br/>
<br/> The -f flag forces integrate to ignore integration history and treat
<br/> all source revisions as unintegrated. It is meant to be used with
<br/> revRange to force reintegration of specific, previously integrated
<br/> revisions.
<br/>
<br/> The -O flags cause more information to be output for each file opened:
<br/>
<br/> -Ob Show the base revision for the merge (if any).
<br/> -Or Show the resolve(s) that are being scheduled.
<br/>
<br/> The -R flags modify the way resolves are scheduled:
<br/>
<br/> -Rb Schedules 'branch resolves' instead of branching new
<br/> target files automatically.
<br/>
<br/> -Rd Schedules 'delete resolves' instead of deleting
<br/> target files automatically.
<br/>
<br/> -Rs Skips cherry-picked revisions already integrated.
<br/> This can improve merge results, but can also cause
<br/> multiple resolves per file to be scheduled.
<br/>
<br/> The -Di flag modifies the way deleted revisions are treated. If the
<br/> source file has been deleted and re-added, revisions that precede
<br/> the deletion will be considered to be part of the same source file.
<br/> By default, re-added files are considered to be unrelated to the
<br/> files of the same name that preceded them.
<br/>
<br/> The -h flag leaves the target files at the revision currently synced
<br/> to the client (the '#have' revision). By default, target files are
<br/> automatically synced to the head revision by 'p4 integrate'.
<br/>
<br/> The -m flag limits integration to the first 'max' number of files.
<br/>
<br/> The -n flag displays a preview of integration, without actually
<br/> doing anything.
<br/>
<br/> The -q flag suppresses normal output messages. Messages regarding
<br/> errors or exceptional conditions are displayed.
<br/>
<br/> If -c changelist# is specified, the files are opened in the
<br/> designated numbered pending changelist instead of the 'default'
<br/> changelist.
<br/>
<br/> The -v flag causes a 'virtual' integration that does not modify
<br/> client workspace files unless target files need to be resolved.
<br/> After submitting a virtual integration, 'p4 sync' can be used to
<br/> update the workspace.
<br/>
<br/> Integration is not supported for files with propagating attributes
<br/> from an edge server in a distributed environment. Depending on the
<br/> integration action, target, and source, either the integration or
<br/> resolve command will fail.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Client.IntegrateFiles(System.Collections.Generic.IList{Perforce.P4.FileSpec},Perforce.P4.FileSpec,Perforce.P4.Options)">
<summary>
</summary>
<param name="toFiles"></param>
<param name="fromFile"></param>
<param name="options"></param>
<returns></returns>
<remarks>
<br/><b>p4 help integrate</b>
<br/>
<br/> integrate -- Integrate one set of files into another
<br/>
<br/> p4 integrate [options] fromFile[revRange] toFile
<br/> p4 integrate [options] -b branch [-r] [toFile[revRange] ...]
<br/> p4 integrate [options] -b branch -s fromFile[revRange] [toFile ...]
<br/> p4 integrate [options] -S stream [-r] [-P parent] [file[revRange] ...]
<br/>
<br/> options: -c changelist# -Di -f -h -O<flags> -n -m max -R<flags> -q -v
<br/>
<br/> 'p4 integrate' integrates one set of files (the 'source') into
<br/> another (the 'target').
<br/>
<br/> (See also 'p4 merge' and 'p4 copy', variants of 'p4 integrate' that
<br/> may be easier and more effective for the task at hand.)
<br/>
<br/> Using the client workspace as a staging area, 'p4 integrate' adds and
<br/> deletes target files per changes in the source, and schedules all
<br/> other affected target files to be resolved. Target files outside of
<br/> the current client view are not affected. Source files need not be
<br/> within the client view.
<br/>
<br/> 'p4 resolve' must be used to merge file content, and to resolve
<br/> filename and filetype changes. 'p4 submit' commits integrated files
<br/> to the depot. Unresolved files may not be submitted. Integrations
<br/> can be shelved with 'p4 shelve' and abandoned with 'p4 revert'. The
<br/> commands 'p4 integrated' and 'p4 filelog' display integration history.
<br/>
<br/> When 'p4 integrate' schedules a workspace file to be resolved, it
<br/> leaves it read-only. 'p4 resolve' can operate on a read-only file.
<br/> For other pre-submit changes, 'p4 edit' must be used to make the
<br/> file writable.
<br/>
<br/> Source and target files can be specified either on the 'p4 integrate'
<br/> command line or through a branch view. On the command line, fromFile
<br/> is the source file set and toFile is the target file set. With a
<br/> branch view, one or more toFile arguments can be given to limit the
<br/> scope of the target file set.
<br/>
<br/> revRange is a revision or a revision range that limits the span of
<br/> source history to be probed for unintegrated revisions. revRange
<br/> can be used on fromFile, or on toFile, but not on both. When used on
<br/> toFile, it refers to source revisions, not to target revisions. For
<br/> details about revision specifiers, see 'p4 help revisions'.
<br/>
<br/> The -S flag makes 'p4 integrate' use a generated branch view that maps
<br/> a stream (or its underlying real stream) to its parent. With -r, the
<br/> direction of the mapping is reversed. -P can be used to generate the
<br/> branch view using a parent stream other than the stream's actual
<br/> parent. Note that to submit integrated stream files, the current
<br/> client must be switched to the target stream, or to a virtual child
<br/> stream of the target stream.
<br/>
<br/> The -b flag makes 'p4 integrate' use a user-defined branch view.
<br/> (See 'p4 help branch'.) The source is the left side of the branch view
<br/> and the target is the right side. With -r, the direction is reversed.
<br/>
<br/> The -s flag can be used with -b to cause fromFile to be treated as
<br/> the source, and both sides of the branch view to be treated as the
<br/> target, per the branch view mapping. Optional toFile arguments may
<br/> be given to further restrict the scope of the target file set. The
<br/> -r flag is ignored when -s is used.
<br/>
<br/> Note that 'p4 integrate' automatically adusts source-to-target
<br/> mappings for moved and renamed files. (Adjustment occurs only if
<br/> the 'p4 move' command was used to move/rename files.) The scope of
<br/> source and target file sets must include both the old-named and the
<br/> new-named files for mappings to be adjusted. A filename resolve is
<br/> scheduled for each remapped file to allow the target to be moved to
<br/> match the source.
<br/>
<br/> The -f flag forces integrate to ignore integration history and treat
<br/> all source revisions as unintegrated. It is meant to be used with
<br/> revRange to force reintegration of specific, previously integrated
<br/> revisions.
<br/>
<br/> The -O flags cause more information to be output for each file opened:
<br/>
<br/> -Ob Show the base revision for the merge (if any).
<br/> -Or Show the resolve(s) that are being scheduled.
<br/>
<br/> The -R flags modify the way resolves are scheduled:
<br/>
<br/> -Rb Schedules 'branch resolves' instead of branching new
<br/> target files automatically.
<br/>
<br/> -Rd Schedules 'delete resolves' instead of deleting
<br/> target files automatically.
<br/>
<br/> -Rs Skips cherry-picked revisions already integrated.
<br/> This can improve merge results, but can also cause
<br/> multiple resolves per file to be scheduled.
<br/>
<br/> The -Di flag modifies the way deleted revisions are treated. If the
<br/> source file has been deleted and re-added, revisions that precede
<br/> the deletion will be considered to be part of the same source file.
<br/> By default, re-added files are considered to be unrelated to the
<br/> files of the same name that preceded them.
<br/>
<br/> The -h flag leaves the target files at the revision currently synced
<br/> to the client (the '#have' revision). By default, target files are
<br/> automatically synced to the head revision by 'p4 integrate'.
<br/>
<br/> The -m flag limits integration to the first 'max' number of files.
<br/>
<br/> The -n flag displays a preview of integration, without actually
<br/> doing anything.
<br/>
<br/> The -q flag suppresses normal output messages. Messages regarding
<br/> errors or exceptional conditions are displayed.
<br/>
<br/> If -c changelist# is specified, the files are opened in the
<br/> designated numbered pending changelist instead of the 'default'
<br/> changelist.
<br/>
<br/> The -v flag causes a 'virtual' integration that does not modify
<br/> client workspace files unless target files need to be resolved.
<br/> After submitting a virtual integration, 'p4 sync' can be used to
<br/> update the workspace.
<br/>
<br/> Integration is not supported for files with propagating attributes
<br/> from an edge server in a distributed environment. Depending on the
<br/> integration action, target, and source, either the integration or
<br/> resolve command will fail.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Client.LabelSync(Perforce.P4.Options,System.String,Perforce.P4.FileSpec[])">
<summary>
</summary>
<param name="files"></param>
<param name="labelName"></param>
<param name="options"></param>
<returns></returns>
<remarks>
<br/><b>p4 help labelsync</b>
<br/>
<br/> labelsync -- Apply the label to the contents of the client workspace
<br/>
<br/> p4 labelsync [-a -d -g -n -q] -l label [file[revRange] ...]
<br/>
<br/> Labelsync causes the specified label to reflect the current contents
<br/> of the client. It records the revision of each file currently synced.
<br/> The label's name can subsequently be used in a revision specification
<br/> as @label to refer to the revision of a file as stored in the label.
<br/>
<br/> Without a file argument, labelsync causes the label to reflect the
<br/> contents of the whole client, by adding, deleting, and updating the
<br/> label. If a file is specified, labelsync updates the specified file.
<br/>
<br/> If the file argument includes a revision specification, that revision
<br/> is used instead of the revision synced by the client. If the specified
<br/> revision is a deleted revision, the label includes that deleted
<br/> revision. See 'p4 help revisions' for details about specifying
<br/> revisions.
<br/>
<br/> If the file argument includes a revision range specification,
<br/> only files selected by the revision range are updated, and the
<br/> highest revision in the range is used.
<br/>
<br/> The -a flag adds the specified file to the label.
<br/>
<br/> The -d deletes the specified file from the label, regardless of
<br/> revision.
<br/>
<br/> The -n flag previews the operation without altering the label.
<br/>
<br/> Only the owner of a label can run labelsync on that label. A label
<br/> that has its Options: field set to 'locked' cannot be updated. A
<br/> label without an owner can be labelsync'd by any user.
<br/>
<br/> The -q flag suppresses normal output messages. Messages regarding
<br/> errors or exceptional conditions are displayed.
<br/>
<br/> The -g flag should be used on an Edge Server to update a global
<br/> label. Note that in this case, the client should be a global client.
<br/> Configuring rpl.labels.global=1 reverses this default and causes this
<br/> flag to have the opposite meaning.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Client.LabelSync(System.Collections.Generic.IList{Perforce.P4.FileSpec},System.String,Perforce.P4.Options)">
<summary>
</summary>
<param name="toFiles"></param>
<param name="labelName"></param>
<param name="options"></param>
<returns></returns>
<remarks>
<br/><b>p4 help labelsync</b>
<br/>
<br/> labelsync -- Apply the label to the contents of the client workspace
<br/>
<br/> p4 labelsync [-a -d -g -n -q] -l label [file[revRange] ...]
<br/>
<br/> Labelsync causes the specified label to reflect the current contents
<br/> of the client. It records the revision of each file currently synced.
<br/> The label's name can subsequently be used in a revision specification
<br/> as @label to refer to the revision of a file as stored in the label.
<br/>
<br/> Without a file argument, labelsync causes the label to reflect the
<br/> contents of the whole client, by adding, deleting, and updating the
<br/> label. If a file is specified, labelsync updates the specified file.
<br/>
<br/> If the file argument includes a revision specification, that revision
<br/> is used instead of the revision synced by the client. If the specified
<br/> revision is a deleted revision, the label includes that deleted
<br/> revision. See 'p4 help revisions' for details about specifying
<br/> revisions.
<br/>
<br/> If the file argument includes a revision range specification,
<br/> only files selected by the revision range are updated, and the
<br/> highest revision in the range is used.
<br/>
<br/> The -a flag adds the specified file to the label.
<br/>
<br/> The -d deletes the specified file from the label, regardless of
<br/> revision.
<br/>
<br/> The -n flag previews the operation without altering the label.
<br/>
<br/> Only the owner of a label can run labelsync on that label. A label
<br/> that has its Options: field set to 'locked' cannot be updated. A
<br/> label without an owner can be labelsync'd by any user.
<br/>
<br/> The -q flag suppresses normal output messages. Messages regarding
<br/> errors or exceptional conditions are displayed.
<br/>
<br/> The -g flag should be used on an Edge Server to update a global
<br/> label. Note that in this case, the client should be a global client.
<br/> Configuring rpl.labels.global=1 reverses this default and causes this
<br/> flag to have the opposite meaning.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Client.LockFiles(Perforce.P4.Options,Perforce.P4.FileSpec[])">
<summary>
</summary>
<param name="files"></param>
<param name="options"></param>
<returns></returns>
<remarks>
<br/><b>p4 help lock</b>
<br/>
<br/> lock -- Lock an open file to prevent it from being submitted
<br/>
<br/> p4 lock [-c changelist#] [file ...]
<br/>
<br/> The specified files are locked in the depot, preventing any user
<br/> other than the current user on the current client from submitting
<br/> changes to the files. If a file is already locked, the lock request
<br/> is rejected. If no file names are specified, all files in the
<br/> specified changelist are locked. If changelist number is omitted,
<br/> files in the default changelist are locked.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Client.MoveFiles(Perforce.P4.FileSpec,Perforce.P4.FileSpec,Perforce.P4.Options)">
<summary>
</summary>
<param name="files"></param>
<param name="options"></param>
<returns></returns>
<remarks>
<br/><b>p4 help move</b>
<br/>
<br/> move -- move file(s) from one location to another
<br/> rename -- synonym for 'move'
<br/>
<br/> p4 move [-c changelist#] [-f -n -k] [-t filetype] fromFile toFile
<br/>
<br/> Move takes an already opened file and moves it from one client
<br/> location to another, reopening it as a pending depot move. When
<br/> the file is submitted with 'p4 submit', its depot file is moved
<br/> accordingly.
<br/>
<br/> Wildcards in fromFile and toFile must match. The fromFile must be
<br/> a file open for add or edit.
<br/>
<br/> 'p4 opened' lists pending moves. 'p4 diff' can compare a moved
<br/> client file with its depot original, 'p4 sync' can schedule an
<br/> update of a moved file, and 'p4 resolve' can resolve the update.
<br/>
<br/> A client file can be moved many times before it is submitted.
<br/> Moving a file back to its original location will undo a pending
<br/> move, leaving unsubmitted content intact. Using 'p4 revert'
<br/> undoes the move and reverts the unsubmitted content.
<br/>
<br/> If -c changelist# is specified, the file is reopened in the
<br/> specified pending changelist as well as being moved.
<br/>
<br/> The -f flag forces a move to an existing target file. The file
<br/> must be synced and not opened. The originating source file will
<br/> no longer be synced to the client.
<br/>
<br/> If -t filetype is specified, the file is assigned that filetype.
<br/> If the filetype is a partial filetype, the partial filetype is
<br/> combined with the current filetype. See 'p4 help filetypes'.
<br/>
<br/> The -n flag previews the operation without moving files.
<br/>
<br/> The -k flag performs the rename on the server without modifying
<br/> client files. Use with caution, as an incorrect move can cause
<br/> discrepancies between the state of the client and the corresponding
<br/> server metadata.
<br/>
<br/> The 'move' command requires a release 2009.1 or newer client. The
<br/> '-f' flag requires a 2010.1 client.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Client.ReopenFiles(Perforce.P4.Options,Perforce.P4.FileSpec[])">
<summary>
</summary>
<param name="options"></param>
<param name="files"></param>
<returns></returns>
<remarks>
<br/><b>p4 help reopen</b>
<br/>
<br/> reopen -- Change the filetype of an open file or move it to
<br/> another changelist
<br/>
<br/> p4 reopen [-c changelist#] [-t filetype] file ...
<br/>
<br/> Reopen an open file for the current user in order to move it to a
<br/> different changelist or change its filetype.
<br/>
<br/> The target changelist must exist; you cannot create a changelist by
<br/> reopening a file. To move a file to the default changelist, use
<br/> 'p4 reopen -c default'.
<br/>
<br/> If -t filetype is specified, the file is assigned that filetype. If
<br/> a partial filetype is specified, it is combined with the current
<br/> filetype. For details, see 'p4 help filetypes'.
<br/>
<br/>
</remarks>
</member>
<!-- Badly formed XML comment ignored for member "M:Perforce.P4.Client.ResolveFiles(Perforce.P4.Options,Perforce.P4.FileSpec[])" -->
<member name="M:Perforce.P4.Client.ResolveFiles(Perforce.P4.Client.ResolveFileDelegate,Perforce.P4.Options,Perforce.P4.FileSpec[])">
<summary>
Resolve files
</summary>
<param name="resolveHandler"></param>
<param name="options"></param>
<param name="files"></param>
<returns></returns>
<remarks>
The caller must either
1) set an automatic resolution (-as, -am.-af, -at, or -ay),
2) provide a callback function of type <see cref="T:Perforce.P4.P4Server.PromptHandlerDelegate"/> to
respond to the prompts, or 3) provide a dictionary which contains responses to the prompts.
<br/>
<br/><b>p4 help resolve</b>
<br/>
<br/> resolve -- Resolve integrations and updates to workspace files
<br/>
<br/> p4 resolve [options] [file ...]
<br/>
<br/> options: -A<flags> -a<flags> -d<flags> -f -n -N -o -t -v
<br/> -c changelist#
<br/>
<br/> 'p4 resolve' resolves changes to files in the client workspace.
<br/>
<br/> 'p4 resolve' works only on files that have been scheduled to be
<br/> resolved. The commands that can schedule resolves are: 'p4 sync',
<br/> 'p4 update', 'p4 submit', 'p4 merge', and 'p4 integrate'. Files must
<br/> be resolved before they can be submitted.
<br/>
<br/> Resolving involves two sets of files, a source and a target. The
<br/> target is a set of depot files that maps to opened files in the
<br/> client workspace. When resolving an integration, the source is a
<br/> different set of depot files than the target. When resolving an
<br/> update, the source is the same set of depot files as the target,
<br/> at a different revision.
<br/>
<br/> The 'p4 resolve' file argument specifies the target. If the file
<br/> argument is omitted, all unresolved files are resolved.
<br/>
<br/> Resolving can modify workspace files. To back up files, use 'p4
<br/> shelve' before using 'p4 resolve'.
<br/>
<br/> The resolve process is a classic three-way merge. The participating
<br/> files are referred to as follows:
<br/>
<br/> 'yours' The target file open in the client workspace
<br/> 'theirs' The source file in the depot
<br/> 'base' The common ancestor; the highest revision of the
<br/> source file already accounted for in the target.
<br/> 'merged' The merged result.
<br/>
<br/> Filenames, filetypes, and text file content can be resolved by
<br/> accepting 'yours', 'theirs', or 'merged'. Branching, deletion, and
<br/> binary file content can be resolved by accepting either 'yours' or
<br/> 'theirs'.
<br/>
<br/> When resolving integrated changes, 'p4 resolve' distinguishes among
<br/> four results: entirely yours, entirely theirs, a pure merge, or an
<br/> edited merge. The distinction is recorded when resolved files are
<br/> submitted, and will be used by future commands to determine whether
<br/> integration is needed.
<br/>
<br/> In all cases, accepting 'yours' leaves the target file in its current
<br/> state. The result of accepting 'theirs' is as follows:
<br/>
<br/> Content: The target file content is overwritten.
<br/> Attribute: The target's attributes are replaced.
<br/> Branching: A new target is branched.
<br/> Deletion: The target file is deleted.
<br/> Filename: The target file is moved or renamed.
<br/> Filetype: The target file's type is changed.
<br/>
<br/> For each unresolved change, the user is prompted to accept a result.
<br/> Content and non-content changes are resolved separately. For content,
<br/> 'p4 resolve' places the merged result into a temporary file in the
<br/> client workspace. If there are any conflicts, the merged file contains
<br/> conflict markers that must be removed by the user.
<br/>
<br/> 'p4 resolve' displays a count of text diffs and conflicts, and offers
<br/> the following prompts:
<br/>
<br/> Accept:
<br/> at Keep only changes to their file.
<br/> ay Keep only changes to your file.
<br/> * am Keep merged file.
<br/> * ae Keep merged and edited file.
<br/> * a Keep autoselected file.
<br/>
<br/> Diff:
<br/> * dt See their changes alone.
<br/> * dy See your changes alone.
<br/> * dm See merged changes.
<br/> d Diff your file against merged file.
<br/>
<br/> Edit:
<br/> et Edit their file (read only).
<br/> ey Edit your file (read/write).
<br/> * e Edit merged file (read/write).
<br/>
<br/> Misc:
<br/> * m Run '$P4MERGE base theirs yours merged'.
<br/> (Runs '$P4MERGEUNICODE charset base theirs
<br/> yours merged' if set and the file is a
<br/> unicode file.)
<br/> s Skip this file.
<br/> h Print this help message.
<br/> ^C Quit the resolve operation.
<br/>
<br/> Options marked (*) appear only for text files. The suggested action
<br/> will be displayed in brackets.
<br/>
<br/> The 'merge' (m) option enables you to invoke your own merge program, if
<br/> one is configured using the $P4MERGE environment variable. Four files
<br/> are passed to the program: the base, yours, theirs, and the temporary
<br/> file. The program is expected to write merge results to the temporary
<br/> file.
<br/>
<br/> The -A flag can be used to limit the kind of resolving that will be
<br/> attempted; without it, everything is attempted:
<br/>
<br/> -Aa Resolve attributes.
<br/> -Ab Resolve file branching.
<br/> -Ac Resolve file content changes.
<br/> -Ad Resolve file deletions.
<br/> -Am Resolve moved and renamed files.
<br/> -At Resolve filetype changes.
<br/> -AQ Resolve charset changes.
<br/>
<br/> The -a flag puts 'p4 resolve' into automatic mode. The user is not
<br/> prompted, and files that can't be resolved automatically are skipped:
<br/>
<br/> -as 'Safe' resolve; skip files that need merging.
<br/> -am Resolve by merging; skip files with conflicts.
<br/> -af Force acceptance of merged files with conflicts.
<br/> -at Force acceptance of theirs; overwrites yours.
<br/> -ay Force acceptance of yours; ignores theirs.
<br/>
<br/> The -as flag causes the workspace file to be replaced with their file
<br/> only if theirs has changed and yours has not.
<br/>
<br/> The -am flag causes the workspace file to be replaced with the result
<br/> of merging theirs with yours. If the merge detected conflicts, the
<br/> file is left untouched and unresolved.
<br/>
<br/> The -af flag causes the workspace file to be replaced with the result
<br/> of merging theirs with yours, even if there were conflicts. This can
<br/> leave conflict markers in workspace files.
<br/>
<br/> The -at flag resolves all files by copying theirs into yours. It
<br/> should be used with care, as it overwrites any changes made to the
<br/> file in the client workspace.
<br/>
<br/> The -ay flag resolves all files by accepting yours and ignoring
<br/> theirs. It preserves the content of workspace files.
<br/>
<br/> The -d flags can be used to control handling of whitespace and line
<br/> endings when merging files:
<br/>
<br/> -db Ignore whitespace changes.
<br/> -dw Ignore whitespace altogether.
<br/> -dl Ignores line endings.
<br/>
<br/> The -d flags are also passed to the diff options in the 'p4 resolve'
<br/> dialog. Additional -d flags that modify the diff output but do not
<br/> modify merge behavior include -dn (RCS), -dc (context), -ds (summary),
<br/> and -du (unified). Note that 'p4 resolve' uses text from the client
<br/> file if the files differ only in whitespace.
<br/>
<br/> The -f flag enables previously resolved content to be resolved again.
<br/> By default, after files have been resolved, 'p4 resolve' does not
<br/> process them again.
<br/>
<br/> The -n flag previews the operation without altering files.
<br/>
<br/> The -N flag previews the operation with additional information about
<br/> any non-content resolve actions that are scheduled.
<br/>
<br/> The -o flag displays the base file name and revision to be used
<br/> during the the merge.
<br/>
<br/> The -t flag forces 'p4 resolve' to attempt a textual merge, even for
<br/> files with non-text (binary) types.
<br/>
<br/> The -v flag causes 'p4 resolve' to insert markers for all changes,
<br/> not just conflicts.
<br/>
<br/> The -c flag limits 'p4 resolve' to the files in changelist#.
<br/>
<br/> 'p4 resolve' is not supported for files with propagating attributes
<br/> from an edge server in a distributed environment.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Client.SubmitFiles(Perforce.P4.Options,Perforce.P4.FileSpec)">
<summary>
</summary>
<param name="options"></param>
<param name="files"></param>
<returns></returns>
<remarks>
<br/><b>p4 help submit</b>
<br/>
<br/> submit -- Submit open files to the depot
<br/>
<br/> p4 submit [-r -s -f option --noretransfer 0|1]
<br/> p4 submit [-r -s -f option] file
<br/> p4 submit [-r -f option] -d description
<br/> p4 submit [-r -f option] -d description file
<br/> p4 submit [-r -f option --noretransfer 0|1] -c changelist#
<br/> p4 submit -e shelvedChange#
<br/> p4 submit -i [-r -s -f option]
<br/> --parallel=threads=N[,batch=N][,min=N]
<br/>
<br/> 'p4 submit' commits a pending changelist and its files to the depot.
<br/>
<br/> By default, 'p4 submit' attempts to submit all files in the 'default'
<br/> changelist. Submit displays a dialog where you enter a description
<br/> of the change and, optionally, delete files from the list of files
<br/> to be checked in.
<br/>
<br/> To add files to a changelist before submitting, use any of the
<br/> commands that open client workspace files: 'p4 add', 'p4 edit',
<br/> etc.
<br/>
<br/> If the file parameter is specified, only files in the default
<br/> changelist that match the pattern are submitted.
<br/>
<br/> Files in a stream path can be submitted only by client workspaces
<br/> dedicated to the stream. See 'p4 help client'.
<br/>
<br/> Before committing a changelist, 'p4 submit' locks all the files being
<br/> submitted. If any file cannot be locked or submitted, the files are
<br/> left open in a numbered pending changelist. By default, the files in
<br/> a failed submit operation are left locked unless the
<br/> submit.unlocklocked configurable is set. Files are unlocked even if
<br/> they were manually locked prior to submit if submit fails when
<br/> submit.unlocklocked is set. 'p4 opened' shows unsubmitted files
<br/> and their changelists.
<br/>
<br/> Submit is atomic: if the operation succeeds, all files are updated
<br/> in the depot. If the submit fails, no depot files are updated.
<br/>
<br/> If submit fails, some or all of the files may have been copied to
<br/> the server. By default, retrying a failed submit will transfer all of
<br/> the files again unless the submit.noretransfer configurable is set.
<br/> If submit.noretransfer is set to 1, submit uses digest comparisons to
<br/> to detect if the files have already been transferred in order to
<br/> avoid file re-transfer when retrying a failed submit.
<br/>
<br/> The --noretransfer flag is used to override the submit.noretransfer
<br/> configurable so the user can choose his preferred re-transfer
<br/> behavior during the current submit operation.
<br/>
<br/> The -c flag submits the specified pending changelist instead of the
<br/> default changelist. Additional changelists can be created manually,
<br/> using the 'p4 change' command, or automatically as the result of a
<br/> failed attempt to submit the default changelist.
<br/>
<br/> The -e flag submits a shelved changelist without transferring files
<br/> or modifying the workspace. The shelved change must be owned by
<br/> the person submitting the change, but the client may be different.
<br/> However, files shelved to a stream target may only be submitted by
<br/> a stream client that is mapped to the target stream. In addition,
<br/> files shelved to a non-stream target cannot be submitted by a stream
<br/> client. To submit a shelved change, all files in the shelved change
<br/> must be up to date and resolved. No files may be open in any workspace
<br/> at the same change number. Client submit options (ie revertUnchanged,
<br/> etc) will be ignored. If the submit is successful, the shelved change
<br/> and files are cleaned up, and are no longer available to be unshelved
<br/> or submitted.
<br/>
<br/> The -d flag passes a description into the specified changelist rather
<br/> than displaying the changelist dialog for manual editing. This option
<br/> is useful for scripting, but does not allow you to add jobs or modify
<br/> the default changelist.
<br/>
<br/> The -f flag enables you to override submit options that are configured
<br/> for the client that is submitting the changelist. This flag overrides
<br/> the -r (reopen)flag, if it is specified. See 'p4 help client' for
<br/> details about submit options.
<br/>
<br/> The -i flag reads a changelist specification from the standard input.
<br/> The user's editor is not invoked.
<br/>
<br/> The -r flag reopens submitted files in the default changelist after
<br/> submission.
<br/>
<br/> The -s flag extends the list of jobs to include the fix status
<br/> for each job, which becomes the job's status when the changelist
<br/> is committed. See 'p4 help change' for details.
<br/>
<br/> The --parallel flag specifies options for parallel file transfer. If
<br/> parallel file transfer has been enabled by setting the
<br/> net.parallel.max configurable, and if there are sufficient resources
<br/> across the system, a submit command may execute more rapidly by
<br/> transferring multiple files in parallel. Specify threads=N to request
<br/> files be sent concurrently, using N independent network connections.
<br/> The N threads grab work in batches; specify batch=N to control the
<br/> number of files in a batch. A submit that is too small will not
<br/> initiate parallel file transfers; specify min=N to control the
<br/> minimum number of files in a parallel submit. Requesting progress
<br/> indicators causes the --parallel flag to be ignored.
<br/>
<br/> Using --parallel from an edge server allows parallel file transfer
<br/> from the edge server to the commit server. This uses standard pull
<br/> threads to transfer the files. Note that an adminstrator must insure
<br/> that pull threads can be run on the commit server. The address
<br/> used by the commit server to connect to the edge server must
<br/> be specified in the ExternalAddress field of the edge server spec.
<br/>
<br/> Only 'submit -e' is supported for files with propagating attributes
<br/> from an edge server in a distributed environment.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Client.GetResolvedFiles(Perforce.P4.Options,Perforce.P4.FileSpec[])">
<summary>
</summary>
<param name="options"></param>
<param name="files"></param>
<returns></returns>
<remarks>
<br/><b>p4 help resolved</b>
<br/>
<br/> resolved -- Show files that have been resolved but not submitted
<br/>
<br/> p4 resolved [-o] [file ...]
<br/>
<br/> 'p4 resolved' lists file updates and integrations that have been
<br/> resolved but not yet submitted. To see unresolved integrations,
<br/> use 'p4 resolve -n'. To see already submitted integrations, use
<br/> 'p4 integrated'.
<br/>
<br/> If a depot file path is specified, the output lists resolves for
<br/> 'theirs' files that match the specified path. If a client file
<br/> path is specified, the output lists resolves for 'yours' files
<br/> that match the specified path.
<br/>
<br/> The -o flag reports the revision used as the base during the
<br/> resolve.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Client.GetResolvedFiles(System.Collections.Generic.IList{Perforce.P4.FileSpec},Perforce.P4.Options)">
<summary>
</summary>
<param name="Files"></param>
<param name="options"></param>
<returns></returns>
</member>
<member name="M:Perforce.P4.Client.RevertFiles(Perforce.P4.Options,Perforce.P4.FileSpec[])">
<summary>
</summary>
<param name="options"><cref>RevertFilesOptions</cref></param>
<param name="files"></param>
<returns></returns>
<remarks>
<br/><b>p4 help revert</b>
<br/>
<br/> revert -- Discard changes from an opened file
<br/>
<br/> p4 revert [-a -n -k -w -c changelist# -C client] file ...
<br/>
<br/> Revert an open file to the revision that was synced from the depot,
<br/> discarding any edits or integrations that have been made. You must
<br/> explicitly specify the files to be reverted. Files are removed from
<br/> the changelist in which they are open. Locked files are unlocked.
<br/>
<br/> The -a flag reverts only files that are open for edit, add, or
<br/> integrate and are unchanged or missing. Files with pending
<br/> integration records are left open. The file arguments are optional
<br/> when -a is specified.
<br/>
<br/> The -n flag displays a preview of the operation.
<br/>
<br/> The -k flag marks the file as reverted in server metadata without
<br/> altering files in the client workspace.
<br/>
<br/> The -w flag causes files that are open for add to be deleted from the
<br/> workspace when they are reverted.
<br/>
<br/> The -c flag reverts files that are open in the specified changelist.
<br/>
<br/> The -C flag allows a user to specify the workspace that has the file
<br/> opened rather than defaulting to the current client workspace. When
<br/> this option is used, the '-k' flag is also enabled and the check for
<br/> matching user is disabled. The -C flag requires 'admin' access, which
<br/> is granted by 'p4 protect'.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Client.RevertFiles(System.Collections.Generic.IList{Perforce.P4.FileSpec},Perforce.P4.Options)">
<summary>
</summary>
<param name="Files"></param>
<param name="options"></param>
<returns></returns>
</member>
<member name="M:Perforce.P4.Client.ShelveFiles(Perforce.P4.Options,Perforce.P4.FileSpec[])">
<summary>
</summary>
<param name="options"></param>
<param name="files"></param>
<returns></returns>
<remarks>
<br/><b>p4 help shelve</b>
<br/>
<br/> shelve -- Store files from a pending changelist into the depot
<br/>
<br/> p4 shelve [-p] [files]
<br/> p4 shelve [-a option] [-p] -i [-f | -r]
<br/> p4 shelve [-a option] [-p] -r -c changelist#
<br/> p4 shelve [-a option] [-p] -c changelist# [-f] [file ...]
<br/> p4 shelve -d -c changelist# [-f] [file ...]
<br/>
<br/> 'p4 shelve' creates, modifies or deletes shelved files in a pending
<br/> changelist. Shelved files remain in the depot until they are deleted
<br/> (using 'p4 shelve -d') or replaced by subsequent shelve commands.
<br/> After 'p4 shelve', the user can revert the files and restore them
<br/> later using 'p4 unshelve'. Other users can 'p4 unshelve' the stored
<br/> files into their own workspaces.
<br/>
<br/> Files that have been shelved can be accessed by the 'p4 diff',
<br/> 'p4 diff2', 'p4 files' and 'p4 print' commands using the revision
<br/> specification '@=change', where 'change' is the pending changelist
<br/> number.
<br/>
<br/> By default, 'p4 shelve' creates a changelist, adds files from the
<br/> user's default changelist, then shelves those files in the depot.
<br/> The user is presented with a text changelist form displayed using
<br/> the editor configured using the $P4EDITOR environment variable.
<br/>
<br/> If a file pattern is specified, 'p4 shelve' shelves the files that
<br/> match the pattern.
<br/>
<br/> The -i flag reads the pending changelist specification with shelved
<br/> files from the standard input. The user's editor is not invoked.
<br/> To modify an existing changelist with shelved files, specify the
<br/> changelist number using the -c flag.
<br/>
<br/> The -c flag specifies the pending changelist that contains shelved
<br/> files to be created, deleted, or modified. Only the user and client
<br/> of the pending changelist can add or modify its shelved files. Any
<br/> files specified by the file pattern must already be opened in the
<br/> specified changelist; use 'p4 reopen' to move an opened file from
<br/> one changelist to another.
<br/>
<br/> The -f (force) flag must be used with the -c or -i flag to overwrite
<br/> any existing shelved files in a pending changelist.
<br/>
<br/> The -r flag (used with -c or -i) enables you to replace all shelved
<br/> files in that changelist with the files opened in your own workspace
<br/> at that changelist number. Previously shelved files will be deleted.
<br/> Only the user and client workspace of the pending changelist can
<br/> replace its shelved files.
<br/>
<br/> The -a flag enables you to handle unchanged files similarly to some
<br/> client submit options, namely 'submitunchanged' and 'leaveunchanged'.
<br/> The default behavior of shelving all files corresponds to the
<br/> 'submitunchanged' option. The 'leaveunchanged' option only shelves
<br/> changed files, and then leaves the files opened in the pending
<br/> changelist on the client.
<br/>
<br/> The -d flag (used with -c) deletes the shelved files in the specified
<br/> changelist so that they can no longer be unshelved. By default, only
<br/> the user and client of the pending changelist can delete its shelved
<br/> files. A user with 'admin' access can delete shelved files by including
<br/> the -f flag to force the operation.
<br/>
<br/> The -p flag promotes a shelved change from an edge server to a commit
<br/> server where it can be accessed by other edge servers participating
<br/> in the distributed configuration. Once a shelved change has been
<br/> promoted, all subsequent local modifications to the shelf are also
<br/> pushed to the commit server and remain until the shelf is deleted.
<br/> Once a shelf has been created, the combination of flags '-p -c' will
<br/> promote the shelf without modification unless '-f' or '-r' are also
<br/> used to update the shelved files before promotion.
<br/>
<br/> 'p4 shelve' is not supported for files with propagating attributes
<br/> from an edge server in a distributed environment.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Client.ShelveFiles(System.Collections.Generic.IList{Perforce.P4.FileSpec},Perforce.P4.Options)">
<summary>
</summary>
<param name="Files"></param>
<param name="options"></param>
<returns></returns>
</member>
<member name="M:Perforce.P4.Client.SyncFiles(Perforce.P4.Options,Perforce.P4.FileSpec[])">
<summary>
</summary>
<param name="options"></param>
<param name="files"></param>
<returns></returns>
<remarks>
<br/><b>p4 help sync</b>
<br/>
<br/> sync -- Synchronize the client with its view of the depot
<br/> flush -- synonym for 'sync -k'
<br/> update -- synonym for 'sync -s'
<br/>
<br/> p4 sync [-f -L -n -N -k -q -r] [-m max] [file[revRange] ...]
<br/> p4 sync [-L -n -N -q -s] [-m max] [file[revRange] ...]
<br/> p4 sync [-L -n -N -p -q] [-m max] [file[revRange] ...]
<br/> --parallel=threads=N[,batch=N][,batchsize=N][,min=N][,minsize=N]
<br/>
<br/> Sync updates the client workspace to reflect its current view (if
<br/> it has changed) and the current contents of the depot (if it has
<br/> changed). The client view maps client and depot file names and
<br/> locations.
<br/>
<br/> Sync adds files that are in the client view and have not been
<br/> retrieved before. Sync deletes previously retrieved files that
<br/> are no longer in the client view or have been deleted from the
<br/> depot. Sync updates files that are still in the client view and
<br/> have been updated in the depot.
<br/>
<br/> By default, sync affects all files in the client workspace. If file
<br/> arguments are given, sync limits its operation to those files.
<br/> The file arguments can contain wildcards.
<br/>
<br/> If the file argument includes a revision specifier, then the given
<br/> revision is retrieved. Normally, the head revision is retrieved.
<br/> See 'p4 help revisions' for help specifying revisions.
<br/>
<br/> If the file argument includes a revision range specification,
<br/> only files selected by the revision range are updated, and the
<br/> highest revision in the range is used.
<br/>
<br/> Normally, sync does not overwrite workspace files that the user has
<br/> manually made writable. Setting the 'clobber' option in the
<br/> client specification disables this safety check.
<br/>
<br/> The -f flag forces resynchronization even if the client already
<br/> has the file, and overwriting any writable files. This flag doesn't
<br/> affect open files.
<br/>
<br/> The -L flag can be used with multiple file arguments that are in
<br/> full depot syntax and include a valid revision number. When this
<br/> flag is used the arguments are processed together by building an
<br/> internal table similar to a label. This file list processing is
<br/> significantly faster than having to call the internal query engine
<br/> for each individual file argument. However, the file argument syntax
<br/> is strict and the command will not run if an error is encountered.
<br/>
<br/> The -n flag previews the operation without updating the workspace.
<br/>
<br/> The -N flag also previews the operation without updating the
<br/> workspace, but reports only a summary of the work the sync would do.
<br/>
<br/> The -k flag updates server metadata without syncing files. It is
<br/> intended to enable you to ensure that the server correctly reflects
<br/> the state of files in the workspace while avoiding a large data
<br/> transfer. Caution: an erroneous update can cause the server to
<br/> incorrectly reflect the state of the workspace.
<br/>
<br/> The -p flag populates the client workspace, but does not update the
<br/> server to reflect those updates. Any file that is already synced or
<br/> opened will be bypassed with a warning message. This option is very
<br/> useful for build clients or when publishing content without the
<br/> need to track the state of the client workspace.
<br/>
<br/> The -q flag suppresses normal output messages. Messages regarding
<br/> errors or exceptional conditions are not suppressed.
<br/>
<br/> The -r flag allows open files which are mapped to new locations
<br/> in the depot to be reopened in the new location. By default, open
<br/> workspace files remain associated with the depot files that they were
<br/> originally opened as.
<br/>
<br/> The -s flag adds a safety check before sending content to the client
<br/> workspace. This check uses MD5 digests to compare the content on the
<br/> clients workspace against content that was last synced. If the file
<br/> has been modified outside of Perforce's control then an error message
<br/> is displayed and the file is not overwritten. This check adds some
<br/> extra processing which will affect the performance of the operation.
<br/> Clients with 'allwrite' and 'noclobber' set do this check by default.
<br/>
<br/> The -m flag limits sync to the first 'max' number of files. This
<br/> option is useful in conjunction with tagged output and the '-n'
<br/> flag, to preview how many files will be synced without transferring
<br/> all the file data.
<br/>
<br/> The --parallel flag specifies options for parallel file transfer. If
<br/> your administrator has enabled parallel file transfer by setting the
<br/> net.parallel.max configurable, and if there are sufficient resources
<br/> across the system, a sync command may execute more rapidly by
<br/> transferring multiple files in parallel. Specify threads=N to request
<br/> files be sent concurrently, using N independent network connections.
<br/> The N threads grab work in batches; specify batch=N to control the
<br/> number of files in a batch, or batchsize=N to control the number of
<br/> bytes in a batch. A sync that is too small will not initiate parallel
<br/> file transfers; specify min=N to control the minimum number of files
<br/> in a parallel sync, or minsize=N to control the minimum number of
<br/> bytes in a parallel sync. Requesting progress indicators causes the
<br/> --parallel flag to be ignored.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Client.SyncFiles(System.Collections.Generic.IList{Perforce.P4.FileSpec},Perforce.P4.Options)">
<summary>
</summary>
<param name="Files"></param>
<param name="options"></param>
<returns></returns>
</member>
<member name="M:Perforce.P4.Client.UnlockFiles(Perforce.P4.Options,Perforce.P4.FileSpec[])">
<summary>
</summary>
<param name="options"></param>
<param name="files"></param>
<returns></returns>
<remarks>
<br/><b>p4 help unlock</b>
<br/>
<br/> unlock -- Release a locked file, leaving it open
<br/>
<br/> p4 unlock [-c | -s changelist# | -x] [-f] [file ...]
<br/> p4 -c client unlock [-f] -r
<br/>
<br/> 'p4 unlock' releases locks on the specified files, which must be
<br/> open in the specified pending changelist. If you omit the changelist
<br/> number, the default changelist is assumed. If you omit the file name,
<br/> all locked files are unlocked.
<br/>
<br/> The -s flag unlocks files from a shelved changelist caused by an
<br/> aborted 'submit -e' operation. The -c flag applies to opened files
<br/> in a pending changelist locked by 'p4 lock' or by a failed submit
<br/> of a change that is not shelved.
<br/>
<br/> By default, files can be unlocked only by the changelist owner who
<br/> must also be the person who has the files locked. The -f flag
<br/> enables you to unlock files in changelists owned by other users.
<br/> The -f flag requires 'admin' access, which is granted by 'p4
<br/> protect'.
<br/>
<br/> The -x option unlocks files that are opened 'exclusive' but are
<br/> orphaned (see 'p4 opened -x'). This option only applies to a
<br/> distributed installation where global tracking of these file types
<br/> is necessary across servers.
<br/>
<br/> If a push command from a remote server to this server fails, files
<br/> can be left locked on this server, preventing other users from
<br/> submitting changes to those files. In this case, the user who issued
<br/> the push command can specify the -r flag with the name of the client
<br/> that was used on that remote server to unlock the files on this
<br/> server. An administrator can run 'unlock -f -r' as well.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Client.UnlockFiles(System.Collections.Generic.IList{Perforce.P4.FileSpec},Perforce.P4.Options)">
<summary>
</summary>
<param name="Files"></param>
<param name="options"></param>
<returns></returns>
</member>
<member name="M:Perforce.P4.Client.UnshelveFiles(Perforce.P4.Options,Perforce.P4.FileSpec[])">
<summary>
</summary>
<param name="options"></param>
<param name="files"></param>
<returns></returns>
<remarks>
<br/><b>p4 help unshelve</b>
<br/>
<br/> unshelve -- Restore shelved files from a pending change into a workspace
<br/>
<br/> p4 unshelve -s changelist# [options] [file ...]
<br/> Options: [-f -n] [-c changelist#] [-b branch|-S stream [-P parent]]
<br/>
<br/> 'p4 unshelve' retrieves shelved files from the specified pending
<br/> changelist, opens them in a pending changelist and copies them
<br/> to the invoking user's workspace. Unshelving files from a pending
<br/> changelist is restricted by the user's permissions on the files.
<br/> A successful unshelve operation places the shelved files on the
<br/> user's workspace with the same open action and pending integration
<br/> history as if it had originated from that user and client.
<br/>
<br/> Unshelving a file over an already opened file is permitted if both
<br/> shelved file and opened file are opened for 'edit'. In a distributed
<br/> environment, an additional requirement is that the shelve was created
<br/> on the same edge server. After unshelving, the workspace file is
<br/> flagged as unresolved, and 'p4 resolve' must be run to resolve the
<br/> differences between the shelved file and the workspace file.
<br/>
<br/> Unshelving a file opened for 'add' when the file already exists
<br/> in the depot will result in the file being opened for edit. After
<br/> unshelving, the workspace file is flagged as unresolved, and
<br/> 'p4 resolve' must be run to resolve the differences between the
<br/> shelved file and the depot file at the head revision. Note that
<br/> unshelving a file opened for 'add' over an already opened file is
<br/> not supported.
<br/>
<br/> The -s flag specifies the number of the pending changelist that
<br/> contains the shelved files.
<br/>
<br/> If a file pattern is specified, 'p4 unshelve' unshelves files that
<br/> match the pattern.
<br/>
<br/> The -b flag specifies a branch spec that the shelved files will be
<br/> mapped through prior to being unshelved, allowing files to be shelved
<br/> in one branch and unshelved in another. As with unshelving into an
<br/> open file, it may be necessary to run 'p4 resolve'. In a distributed
<br/> environment, an additional requirement is that the shelve was created
<br/> on the same edge server.
<br/>
<br/> The -S flag uses a generated branch view to map the shelved files
<br/> between the specified stream and its parent stream. The -P flag
<br/> can be used to generate the view using a parent stream other than
<br/> the actual parent.
<br/>
<br/> The -c flag specifies the changelist to which files are unshelved.
<br/> By default, 'p4 unshelve' opens shelved files in the default
<br/> changelist.
<br/>
<br/> The -f flag forces the clobbering of any writeable but unopened files
<br/> that are being unshelved.
<br/>
<br/> The -n flag previews the operation without changing any files or
<br/> metadata.
<br/>
<br/> 'p4 unshelve' is not supported for files with propagating attributes
<br/> from an edge server in a distributed environment.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Client.UnshelveFiles(System.Collections.Generic.IList{Perforce.P4.FileSpec},Perforce.P4.Options)">
<summary>
</summary>
<param name="Files"></param>
<param name="options"></param>
<returns></returns>
</member>
<member name="M:Perforce.P4.Client.GetClientFileMappings(Perforce.P4.FileSpec[])">
<summary>
</summary>
<param name="options"></param>
<param name="files"></param>
<returns></returns>
<remarks>
<br/><b>p4 help where</b>
<br/>
<br/> where -- Show how file names are mapped by the client view
<br/>
<br/> p4 where [file ...]
<br/>
<br/> Where shows how the specified files are mapped by the client view.
<br/> For each argument, three names are produced: the name in the depot,
<br/> the name on the client in Perforce syntax, and the name on the client
<br/> in local syntax.
<br/>
<br/> If the file parameter is omitted, the mapping for all files in the
<br/> current directory and below) is returned.
<br/>
<br/> Note that 'p4 where' does not determine where any real files reside.
<br/> It only displays the locations that are mapped by the client view.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Client.GetClientFileMappings(System.Collections.Generic.IList{Perforce.P4.FileSpec})">
<summary>
</summary>
<param name="Files"></param>
<returns></returns>
</member>
<member name="M:Perforce.P4.Client.CopyFiles(Perforce.P4.Options,Perforce.P4.FileSpec,Perforce.P4.FileSpec[])">
<summary>
</summary>
<param name="options"></param>
<param name="files"></param>
<returns></returns>
<remarks>
<br/><b>p4 help copy</b>
<br/>
<br/> copy -- Copy one set of files to another
<br/>
<br/> p4 copy [options] fromFile[rev] toFile
<br/> p4 copy [options] -b branch [-r] [toFile[rev] ...]
<br/> p4 copy [options] -b branch -s fromFile[rev] [toFile ...]
<br/> p4 copy [options] -S stream [-P parent] [-F] [-r] [toFile[rev] ...]
<br/>
<br/> options: -c changelist# -f -n -v -m max -q
<br/>
<br/> 'p4 copy' copies one set of files (the 'source') into another (the
<br/> 'target').
<br/>
<br/> Using the client workspace as a staging area, 'p4 copy' makes the
<br/> target identical to the source by branching, replacing, or deleting
<br/> files. 'p4 submit' submits copied files to the depot. 'p4 revert'
<br/> can be used to revert copied files instead of submitting them. The
<br/> history of copied files can be shown with 'p4 filelog' or 'p4
<br/> integrated'.
<br/>
<br/> Target files that are already identical to the source, or that are
<br/> outside of the client view, are not affected by 'p4 copy'. Opened,
<br/> non-identical target files cause 'p4 copy' to exit with a warning.
<br/> When 'p4 copy' creates or modifies files in the workspace, it leaves
<br/> them read-only; 'p4 edit' can make them writable. Files opened by
<br/> 'p4 copy' do not need to be resolved.
<br/>
<br/> Source and target files (fromFile and toFile) can be specified on
<br/> the 'p4 copy' command line or through a branch view. On the command
<br/> line, fromFile is the source file set and toFile is the target file
<br/> set. With a branch view, one or more toFile arguments can be given
<br/> to limit the scope of the target file set.
<br/>
<br/> A revision specifier can be used to select the revision to copy; by
<br/> default, the head revision is copied. The revision specifier can be
<br/> used on fromFile, or on toFile, but not on both. When used on toFile,
<br/> it refers to source revisions, not to target revisions. A range may
<br/> not be used as a revision specifier. For revision syntax, see 'p4
<br/> help revisions'.
<br/>
<br/> The -S flag makes 'p4 copy' copy from a stream to its parent.
<br/> Use -r with -S to reverse the copy direction. Note that to submit
<br/> copied stream files, the current client must be switched to the
<br/> target stream, or to a virtual child stream of the target stream.
<br/> The -S flag causes 'p4 copy' to use a generated branch view that
<br/> maps the stream to its parent. -P can be used to generate the
<br/> branch view using a parent stream other than the stream's actual
<br/> parent. The -S flag also makes 'p4 copy' respect a stream's flow.
<br/>
<br/> The -F flag can be used with -S to force copying against a stream's
<br/> expected flow. It can also force -S to generate a branch view based
<br/> on a virtual stream; the mapping itself refers to the underlying
<br/> real stream.
<br/>
<br/> The -b flag makes 'p4 copy' use a user-defined branch view. (See
<br/> 'p4 help branch'.) The source is the left side of the branch view
<br/> and the target is the right side. With -r, the direction is reversed.
<br/>
<br/> The -s flag can be used with -b to cause fromFile to be treated as
<br/> the source, and both sides of the user-defined branch view to be
<br/> treated as the target, per the branch view mapping. Optional toFile
<br/> arguments may be given to further restrict the scope of the target
<br/> file set. -r is ignored when -s is used.
<br/>
<br/> The -c changelist# flag opens files in the designated (numbered)
<br/> pending changelist instead of the default changelist.
<br/>
<br/> The -f flag forces the creation of extra revisions in order to
<br/> explicitly record that files have been copied. Deleted source files
<br/> will be copied if they do not exist in the target, and files that are
<br/> already identical will be copied if they are not connected by existing
<br/> integration records.
<br/>
<br/> The -n flag displays a preview of the copy, without actually doing
<br/> anything.
<br/>
<br/> The -m flag limits the actions to the first 'max' number of files.
<br/>
<br/> The -q flag suppresses normal output messages. Messages regarding
<br/> errors or exceptional conditions are displayed.
<br/>
<br/> The -v flag causes a 'virtual' copy that does not modify client
<br/> workspace files. After submitting a virtual integration, 'p4 sync'
<br/> can be used to update the workspace.
<br/>
<br/> 'p4 copy' is not supported for files with propagating attributes
<br/> from an edge server in a distributed environment.
<br/>
<br/>
</remarks>
</member>
<!-- Badly formed XML comment ignored for member "M:Perforce.P4.Client.MergeFiles(Perforce.P4.Options,Perforce.P4.FileSpec,Perforce.P4.FileSpec[])" -->
<member name="T:Perforce.P4.ClientMetadata">
<summary>
Metadata from the client associated with a connection.
</summary>
</member>
<member name="M:Perforce.P4.ClientMetadata.FromGetClientMetadataCmdTaggedOutput(Perforce.P4.TaggedObject)">
<summary>
Read the fields from the tagged output of an info command
</summary>
<param name="objectInfo">Tagged output from the 'info' command</param>
</member>
<member name="T:Perforce.P4.ConnectionStatus">
<summary>
Flags for the server connection status.
</summary>
</member>
<member name="F:Perforce.P4.ConnectionStatus.Disconnected">
<summary>
Disconnected from server.
</summary>
</member>
<member name="F:Perforce.P4.ConnectionStatus.Connected">
<summary>
Connected to server.
</summary>
</member>
<member name="T:Perforce.P4.Connection">
<summary>
Represents the logical connection between a specific Perforce
Server instance and a specific client application.
</summary>
</member>
<member name="M:Perforce.P4.Connection.ReleaseConnection">
<summary>
Release the connection held by the bridge to the server. This will cause the
bridge to call init before the next command is run, forcing it to reinitialize
any cached connection settings.
</summary>
</member>
<member name="M:Perforce.P4.Connection.Login(System.String,Perforce.P4.Options,System.String)">
<summary>
Run a Login on the Perforce Server
</summary>
<param name="password">User' password</param>
<param name="options">Login options (see remarks in help file)</param>
<param name="options">Login as user (see remarks in help file)</param>
<returns>Success/Failure</returns>
<remarks>
<br/><b>p4 help login</b>
<br/>
<br/> login -- Log in to Perforce by obtaining a session ticket
<br/>
<br/> p4 login [-a -p] [-h <host>] [user]
<br/> p4 login [-s]
<br/>
<br/> The login command enables a user to access Perforce until the session
<br/> expires or the user logs out.
<br/>
<br/> When a user logs in to Perforce, they are prompted for a password
<br/> If they enter the correct password, they are issued a ticket. The
<br/> ticket expires when the default timeout value has been reached and
<br/> is valid only for the host machine where the 'login' command was
<br/> executed (see below for exception).
<br/>
<br/> The ticket can be used anywhere that a password can be used.
<br/>
<br/> Example: p4 -P <ticket value> changes -m1
<br/>
<br/> The -a flag causes the server to issue a ticket that is valid on all
<br/> host machines.
<br/>
<br/> The -h flag causes the server to issue a ticket that is valid on the
<br/> specified host (IP address). This flag is typically used together
<br/> with the -p flag to acquire a ticket that can be used on a different
<br/> machine.
<br/>
<br/> The -p flag displays the ticket, but does not store it on the client
<br/> machine.
<br/>
<br/> The -s flag displays the status of the current ticket (if there is
<br/> one).
<br/>
<br/> Specifying a username as an argument to 'p4 login' requires 'super'
<br/> access, which is granted by 'p4 protect'. In this case, 'p4 login'
<br/> does not prompt for the password (you must already be logged in).
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Connection.Login(System.String,Perforce.P4.Options)">
<summary>
Login to the Perforce Server
</summary>
<param name="password">User' password</param>
<param name="options">Login options (see remarks in help file)</param>
<returns>Success/Failure</returns>
<remarks>
<br/><b>p4 help login</b>
<br/>
<br/> login -- Log in to Perforce by obtaining a session ticket
<br/>
<br/> p4 login [-a -p] [-h <host>] [user]
<br/> p4 login [-s]
<br/>
<br/> The login command enables a user to access Perforce until the session
<br/> expires or the user logs out.
<br/>
<br/> When a user logs in to Perforce, they are prompted for a password
<br/> If they enter the correct password, they are issued a ticket. The
<br/> ticket expires when the default timeout value has been reached and
<br/> is valid only for the host machine where the 'login' command was
<br/> executed (see below for exception).
<br/>
<br/> The ticket can be used anywhere that a password can be used.
<br/>
<br/> Example: p4 -P <ticket value> changes -m1
<br/>
<br/> The -a flag causes the server to issue a ticket that is valid on all
<br/> host machines.
<br/>
<br/> The -h flag causes the server to issue a ticket that is valid on the
<br/> specified host (IP address). This flag is typically used together
<br/> with the -p flag to acquire a ticket that can be used on a different
<br/> machine.
<br/>
<br/> The -p flag displays the ticket, but does not store it on the client
<br/> machine.
<br/>
<br/> The -s flag displays the status of the current ticket (if there is
<br/> one).
<br/>
<br/> Specifying a username as an argument to 'p4 login' requires 'super'
<br/> access, which is granted by 'p4 protect'. In this case, 'p4 login'
<br/> does not prompt for the password (you must already be logged in).
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Connection.Login(System.String)">
<summary>
Automate the Login to the Perforce Server
</summary>
<param name="password">User' password</param>
<returns>Success/Failure</returns>
<remarks>
Runs the login process. If the server is using ticket based
authentication, actually runs the logon three times. Once to
login and update the ticket file, once to get the ticket from
the server and finally once to get the ticket expiration data.
</remarks>
</member>
<member name="M:Perforce.P4.Connection.Logout(Perforce.P4.Options)">
<summary>
Logout of the Perforce server
</summary>
<param name="options">Logout options (see remarks in help file)</param>
<returns>Success/Failure</returns>
<remarks>
<br/><b>p4 help logout</b>
<br/>
<br/> logout -- Log out from Perforce by removing or invalidating a ticket.
<br/>
<br/> p4 logout [-a] [user]
<br/>
<br/> The logout command removes the ticket on the client. To resume using
<br/> Perforce, the user must log in again.
<br/>
<br/> If you are logged in to Perforce from more than one machine, you can
<br/> log out of Perforce from all machines from which you were logged in
<br/> by specifying the -a flag. The -a flag invalidates the ticket on the
<br/> server. All of your Perforce tickets are invalidated and you are
<br/> logged out.
<br/>
<br/> Specifying a username as an argument to 'p4 logout' requires 'super'
<br/> access, which is granted by 'p4 protect'. Note that the '-a' flag
<br/> must be used to effectively log out a user who has a valid ticket on
<br/> another machine.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Connection.Trust(Perforce.P4.Options,System.String)">
<summary>
Run the client side command trust
</summary>
<param name="options">trust options (see remarks in help file)</param>
<returns>Success/Failure</returns>
<remarks>
<br/><b>p4 trust -h</b>
<br/>
<br/> trust -- Establish trust of an SSL connection
<br/>
<br/> p4 trust [ -l -y -n -d -f -r -i <fingerprint> ]
<br/>
<br/> Establish trust of an SSL connection. This client command manages
<br/> the p4 trust file. This file contains fingerprints of the keys
<br/> received on ssl connections. When an SSL connection is made, this
<br/> file is examined to determine if the SSL connection has been used
<br/> before and if the key is the same as a previously seen key for that
<br/> connection. Establishing trust with a connection prevents undetected
<br/> communication interception (man-in-the-middle) attacks.
<br/>
<br/> Most options are mutually exclusive. Only the -r and -f options
<br/> can be combined with the others.
<br/>
<br/> The -l flag lists existing known fingerprints.
<br/>
<br/> Without options, this command will make a connection to a server
<br/> and examine the key if present, if one cannot be found this command
<br/> will show a fingerprint and ask if this connection should be trusted.
<br/> If a fingerprint exists and does not match, an error that a possible
<br/> security problems exists will be displayed.
<br/>
<br/> The -y flag will cause prompts to be automatically accepted.
<br/>
<br/> The -n flag will cause prompts to be automatically refused.
<br/>
<br/> The -d flag will remove an existing trusted fingerprint of a connection.
<br/>
<br/> The -f flag will force the replacement of a mismatched fingerprint.
<br/>
<br/> The -i flag will allow a specific fingerprint to be installed.
<br/>
<br/> The -r flag specifies that a replacement fingerprint is to be
<br/> affected. Replacement fingerprints can be used in anticipation
<br/> of a server replacing its key. If a replacement fingerprint
<br/> exists for a connection and the primary fingerprint does not match
<br/> while the replacement fnigerprint does, the replacement fingerprint
<br/> will replace the primary. This flag can be combined with -l, -i,
<br/> or -d.
</remarks>
</member>
<member name="M:Perforce.P4.Connection.SetPassword(System.String,System.String)">
<summary>
Set the current user's password on the Perforce server.
</summary>
<param name="OldPassword">User's old password</param>
<param name="NewPassword">User's new password</param>
<returns>Success/Failure</returns>
<remarks>
<br/><b>p4 help passwd</b>
<br/>
<br/> passwd -- Set the user's password on the server (and Windows client)
<br/>
<br/> p4 passwd [-O oldPassword -P newPassword] [user]
<br/>
<br/> 'p4 passwd' sets the user's password on the server.
<br/>
<br/> After a password is set for a user, the same password must be set on
<br/> the client in the environment variable $P4PASSWD to enable the user
<br/> to use all Perforce client applications on that machine. (On Windows,
<br/> you can use 'p4 passwd' to configure the password in the environment.)
<br/>
<br/> 'p4 passwd' prompts for both the old password and the new password
<br/> with character echoing turned off. To delete the password, set it to
<br/> an empty string.
<br/>
<br/> The -O flag provides the old password, avoiding prompting. If you
<br/> specify -O, you must also specify -P.
<br/>
<br/> The -P flag provides the new password, avoiding prompting.
<br/>
<br/> If you are using ticket-based authentication, changing your password
<br/> automatically invalidates all of your tickets and logs you out.
<br/>
<br/> Specifying a username as an argument to 'p4 passwd' requires 'super'
<br/> access granted by 'p4 protect'.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Connection.SetPassword(System.String,System.String,System.String)">
<summary>
Set the a user's password on the Perforce server.
</summary>
<param name="OldPassword">User's old password</param>
<param name="NewPassword">User's new password</param>
<param name="User">User receiving new password</param>
<returns>Success/Failure</returns>
<remarks>
<br/><b>p4 help passwd</b>
<br/>
<br/> passwd -- Set the user's password on the server (and Windows client)
<br/>
<br/> p4 passwd [-O oldPassword -P newPassword] [user]
<br/>
<br/> 'p4 passwd' sets the user's password on the server.
<br/>
<br/> After a password is set for a user, the same password must be set on
<br/> the client in the environment variable $P4PASSWD to enable the user
<br/> to use all Perforce client applications on that machine. (On Windows,
<br/> you can use 'p4 passwd' to configure the password in the environment.)
<br/>
<br/> 'p4 passwd' prompts for both the old password and the new password
<br/> with character echoing turned off. To delete the password, set it to
<br/> an empty string.
<br/>
<br/> The -O flag provides the old password, avoiding prompting. If you
<br/> specify -O, you must also specify -P.
<br/>
<br/> The -P flag provides the new password, avoiding prompting.
<br/>
<br/> If you are using ticket-based authentication, changing your password
<br/> automatically invalidates all of your tickets and logs you out.
<br/>
<br/> Specifying a username as an argument to 'p4 passwd' requires 'super'
<br/> access granted by 'p4 protect'.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Connection.GetActiveTicket">
<summary>
Returns the ticket used by the current connection
</summary>
<returns></returns>
</member>
<member name="M:Perforce.P4.Connection.CreateCommand(System.String,System.Boolean,System.String[])">
<summary>
Create a P4Command that can be run on the connection
</summary>
<param name="cmd">Command name, i.e. 'sync'</param>
<param name="tagged">Flag to create tggged output</param>
<param name="args">The arguments for the command</param>
<returns></returns>
</member>
<member name="M:Perforce.P4.Connection.CancelCommand(Perforce.P4.P4Command)">
<summary>
Cancel a running command
</summary>
<param name="CmdId">Command to cancel</param>
</member>
<member name="M:Perforce.P4.Connection.CancelCommand(System.UInt32)">
<summary>
Cancel a running command
</summary>
<param name="CmdId">Unique Id for the run of the command (P4Command.CommandId)</param>
</member>
<member name="M:Perforce.P4.Connection.GetMapApi">
<summary>
Create a P4.P4MapApi object to be used on the current server connection
</summary>
<returns></returns>
</member>
<member name="M:Perforce.P4.Connection.GetP4EnvironmentVar(System.String)">
<summary>
Get the value of an P4 environment variable
</summary>
<param name="var"></param>
<returns></returns>
<remarks>equivalent of command line "p4 set var"</remarks>
</member>
<member name="M:Perforce.P4.Connection.SetP4EnvironmentVar(System.String,System.String)">
<summary>
Set the value of an P4 environment variable
</summary>
<param name="var"></param>
<param name="val"></param>
<remarks>equivalent ofcommand line "p4 set var=val"</remarks>
</member>
<member name="M:Perforce.P4.Connection.GetP4ConfigFile">
<summary>
The config file used by the connection (if any)
</summary>
</member>
<member name="M:Perforce.P4.Connection.GetP4ConfigFile(System.String)">
<summary>
The config file that will be used by a given directory (if any)
</summary>
</member>
<member name="M:Perforce.P4.Connection.IsFileIgnored(System.String)">
<summary>
Is this file ignored based on the file specified by p4ignore (if any)
</summary>
<param name="path"></param>
<returns></returns>
</member>
<member name="M:Perforce.P4.Connection.GetExistingTicket(System.String)">
<summary>
Get the existing ticket if any for a user on the secified server
</summary>
<param name="port">name|ip:port for the server</param>
<param name="user">user name</param>
<returns></returns>
</member>
<member name="P:Perforce.P4.Connection.ApiLevel">
<summary>
What API level does the server support
</summary>
</member>
<member name="P:Perforce.P4.Connection.LastResults">
<summary>
The results of the last command executed
</summary>
</member>
<member name="P:Perforce.P4.Connection.KeepAlive">
<summary>
Callback to allow the client/user to cancel a long running command
</summary>
</member>
<member name="P:Perforce.P4.Connection.KeepAliveDelay">
<summary>
Time for a command to run before allowing the client/user to cancel a long running command
</summary>
</member>
<member name="T:Perforce.P4.Credential">
<summary>
Specifies user credentials for a specific connection.
</summary>
</member>
<member name="P:Perforce.P4.Credential.TicketHost">
<summary>
Host Name used to store the ticket in the ticket file.
</summary>
<remarks>
The ticket is not always stored in the ticket file. If requested, the Login
command will try to determine the name used in the ticket file to store the
ticket. This is null if the ticket was not stored in the ticket file.
</remarks>
</member>
<member name="T:Perforce.P4.DepotType">
<summary>
The type of the depot.
</summary>
</member>
<member name="F:Perforce.P4.DepotType.Local">
<summary>
A 'local' depot (the default) is managed directly by
the server and its files reside in the server's root
directory.
</summary>
</member>
<member name="F:Perforce.P4.DepotType.Remote">
<summary>
A 'remote' depot refers to files in another Perforce
server.
</summary>
</member>
<member name="F:Perforce.P4.DepotType.Spec">
<summary>
A 'spec' depot automatically archives all edited forms
(branch, change, client, depot, group, job, jobspec,
protect, triggers, typemap, and user) in special,
read-only files. The files are named:
//depotname/formtype/name[suffix]. Updates to jobs made
by the 'p4 change', 'p4 fix', and 'p4 submit' commands
are also saved, but other automatic updates such as
as access times or opened files (for changes) are not.
A server can contain only one 'spec' depot.
</summary>
</member>
<member name="F:Perforce.P4.DepotType.Stream">
<summary>
A 'stream' depot is a local depot dedicated to the
storage of files in a stream.
</summary>
</member>
<member name="F:Perforce.P4.DepotType.Archive">
<summary>
An 'archive' depot defines a storage location to which
obsolete revisions may be relocated.
</summary>
</member>
<member name="F:Perforce.P4.DepotType.Unload">
<summary>
An 'unload' depot defines a storage location to which
database records may be unloaded and from which they
may be reloaded.
</summary>
</member>
<member name="T:Perforce.P4.Depot">
<remarks>
<br/><b>p4 help depot</b>
<br/>
<br/> depot -- Create or edit a depot specification
<br/>
<br/> p4 depot name
<br/> p4 depot -d [-f] name
<br/> p4 depot -o name
<br/> p4 depot -i
<br/>
<br/> Create a new depot specification or edit an existing depot
<br/> specification. The specification form is put into a temporary file
<br/> and the editor (configured by the environment variable $P4EDITOR)
<br/> is invoked.
<br/>
<br/> The depot specification contains the following fields:
<br/>
<br/> Depot: The name of the depot. This name cannot be the same as
<br/> any branch, client, or label name.
<br/>
<br/> Owner: The user who created this depot.
<br/>
<br/> Date: The date that this specification was last modified.
<br/>
<br/> Description: A short description of the depot (optional).
<br/>
<br/> Type: One of the types: 'local', 'stream', 'remote', 'spec',
<br/> 'archive', or 'unload'.
<br/>
<br/> A 'local' depot (the default) is managed directly by
<br/> the server and its files reside in the server's root
<br/> directory.
<br/>
<br/> A 'stream' depot is a local depot dedicated to the
<br/> storage of files in a stream.
<br/>
<br/> A 'remote' depot refers to files in another Perforce
<br/> server.
<br/>
<br/> A 'spec' depot automatically archives all edited forms
<br/> (branch, change, client, depot, group, job, jobspec,
<br/> protect, triggers, typemap, and user) in special,
<br/> read-only files. The files are named:
<br/> //depotname/formtype/name[suffix]. Updates to jobs made
<br/> by the 'p4 change', 'p4 fix', and 'p4 submit' commands
<br/> are also saved, but other automatic updates such as
<br/> as access times or opened files (for changes) are not.
<br/> A server can contain only one 'spec' depot.
<br/>
<br/> A 'archive' depot defines a storage location to which
<br/> obsolete revisions may be relocated.
<br/>
<br/> An 'unload' depot defines a storage location to which
<br/> database records may be unloaded and from which they
<br/> may be reloaded.
<br/>
<br/> Address: For remote depots, the $P4PORT (connection address)
<br/> of the remote server.
<br/>
<br/> Suffix: For spec depots, the optional suffix to be used
<br/> for generated paths. The default is '.p4s'.
<br/>
<br/> Map: Path translation information, in the form of a file
<br/> pattern with a single ... in it. For local depots,
<br/> this path is relative to the server's root directory
<br/> or to server.depot.root if it has been configured
<br/> (Example: depot/...). For remote depots, this path
<br/> refers to the remote server's namespace
<br/> (Example: //depot/...).
<br/>
<br/> SpecMap: For spec depots, the optional description of which
<br/> specs should be saved, as one or more patterns.
<br/>
<br/> The -d flag deletes the specified depot. If any files reside in the
<br/> depot, they must be removed with 'p4 obliterate' before deleting the
<br/> depot. If any archive files remain in the depot directory, they may
<br/> be referenced by lazy copies in other depots; use 'p4 snap' to break
<br/> those linkages. Snap lazy copies prior to obliterating the old depot
<br/> files to allow the obliterate command to remove any unreferenced
<br/> archives from the depot directory. If the depot directory is not
<br/> empty, you must specify the -f flag to delete the depot.
<br/>
<br/> The -o flag writes the depot specification to standard output. The
<br/> user's editor is not invoked.
<br/>
<br/> The -i flag reads a depot specification from standard input. The
<br/> user's editor is not invoked.
<br/>
<br/>
</remarks>
<summary>
A depot specification in a Perforce repository.
</summary>
</member>
<member name="M:Perforce.P4.Depot.FromDepotCmdTaggedOutput(Perforce.P4.TaggedObject)">
<summary>
Read the fields from the tagged output of a depot command
</summary>
<param name="objectInfo">Tagged output from the 'depot' command</param>
</member>
<member name="M:Perforce.P4.Depot.Parse(System.String)">
<summary>
Parse the fields from a depot specification
</summary>
<param name="spec">Text of the depot specification in server format</param>
<returns></returns>
</member>
<member name="F:Perforce.P4.Depot.DepotSpecFormat">
<summary>
Format of a depot specification used to save a depot to the server
</summary>
</member>
<member name="M:Perforce.P4.Depot.ToString">
<summary>
Convert to specification in server format
</summary>
<returns></returns>
</member>
<member name="M:Perforce.P4.Depot.FromDepotsCmdTaggedOutput(Perforce.P4.TaggedObject,System.String,System.Boolean)">
<summary>
Read the fields from the tagged output of a depots command
</summary>
<param name="objectInfo">Tagged output from the 'depots' command</param>
</member>
<member name="T:Perforce.P4.DiffType">
<summary>
The types of diffs returned by the server.
</summary>
</member>
<member name="F:Perforce.P4.DiffType.Content">
<summary>
File contents are different.
</summary>
</member>
<member name="F:Perforce.P4.DiffType.FileType">
<summary>
File contents are identical but file types are different.
</summary>
</member>
<member name="F:Perforce.P4.DiffType.LeftOnly">
<summary>
The left file in the diff has no target file at the
specified name or revision to pair with for a diff.
</summary>
</member>
<member name="F:Perforce.P4.DiffType.RightOnly">
<summary>
The right file in the diff has no source file at the
specified name or revision to pair with for a diff.
</summary>
</member>
<member name="F:Perforce.P4.DiffType.Identical">
<summary>
File content and file types are identical.
</summary>
</member>
<member name="T:Perforce.P4.DepotFileDiff">
<remarks>
<br/><b>p4 help diff2</b>
<br/>
<br/> diff2 -- Compare one set of depot files to another
<br/>
<br/> p4 diff2 [options] fromFile[rev] toFile[rev]
<br/> p4 diff2 [options] -b branch [[fromFile[rev]] toFile[rev]]
<br/> p4 diff2 [options] -S stream [-P parent] [[fromFile[rev]] toFile[rev]]
<br/>
<br/> options: -d<flags> -Od -q -t -u
<br/>
<br/> 'p4 diff2' runs on the server to compare one set of depot files (the
<br/> 'source') to another (the 'target'). Source and target file sets
<br/> can be specified on the 'p4 diff2' command line or through a branch
<br/> view.
<br/>
<br/> With a branch view, fromFile and toFile are optional; fromFile limits
<br/> the scope of the source file set, and toFile limits the scope of the
<br/> target. If only one file argument is given, it is assumed to be
<br/> toFile.
<br/>
<br/> fromFile and toFile can include revision specifiers; by default, the
<br/> head revisions are diffed. See 'p4 help revisions' for details
<br/> about specifying file revisions.
<br/>
<br/> 'p4 diff2' precedes each diffed file pair with a header line of the
<br/> following form:
<br/>
<br/> ==== source#rev (type) - target#rev (type) ==== summary
<br/>
<br/> A source or target file shown as '<none>' means there is no file
<br/> at the specified name or revision to pair with its counterpart.
<br/> The summary status is one of the following: 'identical' means file
<br/> contents and types are identical, 'types' means file contents are
<br/> identical but the types are different, and 'content' means file
<br/> contents are different.
<br/>
<br/> The -b flag makes 'p4 diff2' use a user-defined branch view. (See
<br/> 'p4 help branch'.) The left side of the branch view is the source
<br/> and the right side is the target.
<br/>
<br/> The -S flag makes 'p4 diff2' use a generated branch view that maps
<br/> a stream (or its underlying real stream) to its parent. -P can be
<br/> used to generate the branch view using a parent stream other than
<br/> the stream's actual parent.
<br/>
<br/> The -d<flags> modify the output of diffs as follows:
<br/>
<br/> -dn (RCS)
<br/> -dc[n] (context)
<br/> -ds (summary)
<br/> -du[n] (unified)
<br/> -db (ignore whitespace changes)
<br/> -dw (ignore whitespace)
<br/> -dl (ignore line endings).
<br/>
<br/> The optional argument to -dc/-du specifies number of context lines.
<br/>
<br/> The -Od flag limits output to files that differ.
<br/>
<br/> The -q omits files that have identical content and types and
<br/> suppresses the actual diff for all files.
<br/>
<br/> The -t flag forces 'p4 diff2' to diff binary files.
<br/>
<br/> The -u flag uses the GNU diff -u format and displays only files
<br/> that differ. The file names and dates are in Perforce syntax, but
<br/> the output can be used by the patch program.
<br/>
<br/>
</remarks>
<summary>
A diff between depot files in a Perforce repository.
</summary>
</member>
<member name="M:Perforce.P4.DepotFileDiff.FromGetDepotFileDiffsCmdTaggedOutput(Perforce.P4.TaggedObject,Perforce.P4.Connection,Perforce.P4.Options)">
<summary>
Read the fields from the tagged output of a diff2 command
</summary>
<param name="objectInfo">Tagged output from the 'diff2' command</param>
</member>
<member name="T:Perforce.P4.Group">
<summary>
A user group on a Perforce Server, represented by a P4 Group spec.
</summary>
<remarks>
<br/><b>p4 help group</b>
<br/>
<br/> group -- Change members of user group
<br/>
<br/> p4 group [-a|-A] name
<br/> p4 group -d [-a] name
<br/> p4 group -o name
<br/> p4 group -i [-a|-A]
<br/>
<br/> Create a group or modify the membership of an existing group.
<br/> A group can contain users and other groups. The group specification
<br/> is put into a temporary file and the editor (configured by the
<br/> environment variable $P4EDITOR) is invoked.
<br/>
<br/> A group exists when it has any users or other groups in it, and
<br/> ceases to exist if all users and groups in it are removed.
<br/>
<br/> Each group has MaxResults, MaxScanRows, and MaxLockTime fields,
<br/> which limit the resources committed to operations performed by
<br/> members of the group. For these fields, 'unlimited' or 'unset'
<br/> means no limit for that group. An individual user's limit is the
<br/> highest of any group with a limit to which he belongs, unlimited if
<br/> any of his groups has 'unlimited' for that field, or unlimited
<br/> if he belongs to no group with a limit. See 'p4 help maxresults'
<br/> for more information on MaxResults, MaxScanRows and MaxLockTime.
<br/>
<br/> Each group also has a Timeout field, which specifies how long (in
<br/> seconds) a 'p4 login' ticket remains valid. A value of 'unset' or
<br/> 'unlimited' is equivalent to no timeout. An individual's timeout is
<br/> the highest of any group with a limit to which he belongs, unlimited
<br/> if any of his groups has 'unlimited' for the timeout value, or
<br/> unlimited if he belongs to no group with a limit. See 'p4 help login'
<br/> for more information.
<br/>
<br/> Each group has a PasswordTimeout field, which determines how long a
<br/> password remains valid for members of the group.
<br/>
<br/> A group may be synchronized with an LDAP group by setting the three
<br/> fields: LdapConfig, LdapSearchQuery and LdapUserAttribute. This takes
<br/> the LDAP configuration (see 'p4 ldap') specified by LdapConfig and uses
<br/> it to execute the query stored by LdapSearchQuery. The LDAP attribute
<br/> specified by LdapUserAttribute is taken to be user's username and is
<br/> added to the group's user list. At least one group owner must be set if
<br/> these LDAP fields are used. If the LDAP server requires login for
<br/> read-only queries, then the LDAP configuration must contain valid bind
<br/> credentials in the LDAP spec's SearchBindDN and SearchPasswd fields
<br/>
<br/> The -d flag deletes a group.
<br/>
<br/> The -o flag writes the group specification to standard output. The
<br/> user's editor is not invoked.
<br/>
<br/> The -i flag reads a group specification from standard input. The
<br/> user's editor is not invoked. The new group specification replaces
<br/> the previous one.
<br/>
<br/> The -a flag enables a user without 'super' access to modify the group
<br/> if that user is an 'owner' of that group. Group owners are specified
<br/> in the 'Owners' field of the group spec.
<br/>
<br/> The -A flag enables a user with 'admin' access to add a new group.
<br/> Existing groups may not be modified when this flag is used.
<br/>
<br/> All commands that require access granted by 'p4 protect' consider a
<br/> user's groups when calculating access levels.
<br/>
<br/> 'p4 group' requires 'super' access granted by 'p4 protect' unless
<br/> invoked with the '-a' or '-A' flag by a qualified user.
<br/>
<br/>
</remarks>
<summary>
A group specification in a Perforce repository.
</summary>
</member>
<member name="M:Perforce.P4.Group.#ctor(System.String)">
<summary>
Create a group supplying the name.
</summary>
<param name="id"></param>
</member>
<member name="M:Perforce.P4.Group.#ctor(System.String,System.Int32,System.Int32,System.Int32,System.Int32,System.Int32,System.Collections.Generic.IList{System.String},System.Collections.Generic.IList{System.String},System.Collections.Generic.IList{System.String},Perforce.P4.FormSpec)">
<summary>
Create a group providing all of the properties
</summary>
<param name="id"></param>
<param name="maxResults"></param>
<param name="maxScanRows"></param>
<param name="maxLockTime"></param>
<param name="timeOut"></param>
<param name="passwordTimeout"></param>
<param name="ownerNames"></param>
<param name="userNames"></param>
<param name="subGroups"></param>
</member>
<member name="M:Perforce.P4.Group.FromGroupCmdTaggedOutput(Perforce.P4.TaggedObject)">
<summary>
Read the fields from the tagged output of a group command
</summary>
<param name="objectInfo">Tagged output from the 'user' command</param>
</member>
<member name="M:Perforce.P4.Group.Parse(System.String)">
<summary>
Parse the fields from a group specification
</summary>
<param name="spec">Text of group user specification in server format</param>
<returns></returns>
<remarks>
# A Perforce Group Specification.
#
# Group: The name of the group.
# MaxResults: Limits the rows (unless 'unlimited' or 'unset') any one
# operation can return to the client.
# See 'p4 help maxresults'.
# MaxScanRows: Limits the rows (unless 'unlimited' or 'unset') any one
# operation can scan from any one database table.
# See 'p4 help maxresults'.
# MaxLockTime: Limits the time (in milliseconds, unless 'unlimited' or
# 'unset') any one operation can lock any database table when
# scanning data. See 'p4 help maxresults'.
# Timeout: A time (in seconds, unless 'unlimited' or 'unset')
# which determines how long a 'p4 login'
# session ticket remains valid (default is 12 hours).
# PasswordTimeout:
# A time (in seconds, unless 'unlimited' or 'unset')
# which determines how long a 'p4 password'
# password remains valid (default is unset).
# Subgroups: Other groups automatically included in this group.
# Owners: Users allowed to change this group without requiring super
# access permission.
# Users: The users in the group. One per line.
</remarks>
</member>
<member name="F:Perforce.P4.Group.GroupSpecFormat">
<summary>
Format of a user specification used to save a user to the server
</summary>
</member>
<member name="M:Perforce.P4.Group.ToString">
<summary>
Convert to specification in server format
</summary>
<returns>The specification for the group</returns>
</member>
<member name="P:Perforce.P4.Group.Id">
<summary>
The name of the group.
</summary>
</member>
<member name="P:Perforce.P4.Group.MaxResults">
<summary>
Limits the rows (unless 'unlimited' or 'unset') any one
operation can return to the client.
</summary>
</member>
<member name="P:Perforce.P4.Group.MaxScanRows">
<summary>
Limits the rows (unless 'unlimited' or 'unset') any one
operation can scan from any one database table.
</summary>
</member>
<member name="P:Perforce.P4.Group.MaxLockTime">
<summary>
Limits the time (in milliseconds, unless 'unlimited' or
'unset') any one operation can lock any database table when
scanning data.
</summary>
</member>
<member name="P:Perforce.P4.Group.TimeOut">
<summary>
A time (in seconds, unless 'unlimited' or 'unset')
which determines how long a 'p4 login'
session ticket remains valid (default is 12 hours).
</summary>
</member>
<member name="P:Perforce.P4.Group.PasswordTimeout">
<summary>
A time (in seconds, unless 'unlimited' or 'unset')
which determines how long a 'p4 password'
password remains valid (default is unset).
</summary>
</member>
<member name="P:Perforce.P4.Group.OwnerNames">
<summary>
Users allowed to change this group without requiring super
access permission.
</summary>
</member>
<member name="P:Perforce.P4.Group.UserNames">
<summary>
The users in the group.
</summary>
</member>
<member name="P:Perforce.P4.Group.SubGroups">
<summary>
Other groups automatically included in this group.
</summary>
</member>
<member name="T:Perforce.P4.Counter">
<summary>
A general-purpose counter or named variable in a Perforce repository.
</summary>
</member>
<member name="T:Perforce.P4.File">
<summary>
A versioned object that describes an individual file in a Perforce repository.
</summary>
</member>
<member name="T:Perforce.P4.FileSpec">
<summary>
Identifies one or more specific versioned objects in a Perforce repository.
</summary>
</member>
<member name="M:Perforce.P4.FileSpec.ClientSpecList(System.String[])">
<summary>
Create a list of FileSpec objects from a list of client paths
</summary>
<param name="paths">List of paths</param>
<returns>List of FileSpec objects</returns>
</member>
<member name="M:Perforce.P4.FileSpec.DepotSpecList(System.String[])">
<summary>
Create a list of FileSpec objects from a list of depot paths
</summary>
<param name="paths">List of paths</param>
<returns>List of FileSpec objects</returns>
</member>
<member name="M:Perforce.P4.FileSpec.LocalSpecList(System.String[])">
<summary>
Create a list of FileSpec objects from a list of local paths
</summary>
<param name="paths">List of paths</param>
<returns>List of FileSpec objects</returns>
</member>
<member name="M:Perforce.P4.FileSpec.LocalSpecList(System.Collections.Generic.IList{System.String})">
<summary>
Create a list of FileSpec objects from a list of local paths
</summary>
<param name="paths">List of paths</param>
<returns>List of FileSpec objects</returns>
</member>
<member name="M:Perforce.P4.FileSpec.StripVersion">
<summary>
Create a copy of a filespec without a version
</summary>
</member>
<member name="M:Perforce.P4.FileSpec.UnversionedSpecList(System.Collections.Generic.IList{Perforce.P4.FileSpec})">
<summary>
Copies a list of FileSpec objects without vesions
</summary>
<param name="specs">List of FileSpecs</param>
<returns>List of FileSpec objects</returns>
</member>
<member name="M:Perforce.P4.FileSpec.LocalSpecArray(System.String[])">
<summary>
Create an array of FileSpec objects from a list of local paths
</summary>
<param name="paths">List of paths</param>
<returns>List of FileSpec objects</returns>
</member>
<member name="M:Perforce.P4.FileSpec.LocalSpecArray(System.Collections.Generic.IList{System.String})">
<summary>
Create an array of FileSpec objects from a list of local paths
</summary>
<param name="paths">List of paths</param>
<returns>List of FileSpec objects</returns>
</member>
<member name="M:Perforce.P4.FileSpec.ToStrings(System.Collections.Generic.IList{Perforce.P4.FileSpec})">
<summary>
Copy the non-null entries into a new string array.
</summary>
</member>
<member name="M:Perforce.P4.FileSpec.ToEscapedStrings(System.Collections.Generic.IList{Perforce.P4.FileSpec})">
<summary>
Copy the non-null entries into a new string array
with the paths escaped for special characters
</summary>
</member>
<member name="M:Perforce.P4.FileSpec.ToEscapedStrings(Perforce.P4.FileSpec[])">
<summary>
Copy the non-null entries into a new string array
with the paths escaped for special characters
</summary>
</member>
<member name="M:Perforce.P4.FileSpec.ToStrings(Perforce.P4.FileSpec[])">
<summary>
Copy the non-null entries into a new string array.
</summary>
</member>
<member name="M:Perforce.P4.FileSpec.ToPaths(Perforce.P4.FileSpec[])">
<summary>
Copy the non-null entries into a new string array containing the paths.
</summary>
</member>
<member name="M:Perforce.P4.FileSpec.ToEscapedPaths(Perforce.P4.FileSpec[])">
<summary>
Copy the non-null entries into a new string array containing the paths
escaped for special characters
</summary>
</member>
<member name="M:Perforce.P4.FileSpec.ToEscapedLocalPaths(Perforce.P4.FileSpec[])">
<summary>
Copy the non-null entries into a new string array containing the local paths
escaped for special characters
</summary>
</member>
<member name="T:Perforce.P4.FileAnnotation">
<summary>
Correlates file lines with revision information.
</summary>
</member>
<member name="T:Perforce.P4.FileHistory">
<summary>
Describes a Perforce file revision in detail, including the changelist
number and associated description, action, user, etc. data.
</summary>
</member>
<member name="M:Perforce.P4.FileHistory.ToString">
<summary>
Convert to a string of the format ... #{rev} change {change} {action} on {date} {user}@{client} (type) '{desc}'
</summary>
<returns></returns>
</member>
<member name="M:Perforce.P4.FileHistory.ToString(System.Boolean)">
<summary>
Convert to a string of the format ... #{rev} change {change} {action} on {date}[ {time}] {user}@{client} (type) '{desc}'
</summary>
<param name="includeTime">Include the time as well as the date</param>
<returns></returns>
</member>
<member name="T:Perforce.P4.RevisionIntegrationSummary">
<summary>
Describes an integration, specifying the from file and how
the integration was done.
</summary>
</member>
<member name="T:Perforce.P4.FileIntegrationRecord">
<summary>
Represents submitted or pending integrations.
</summary>
</member>
<member name="T:Perforce.P4.MatchType">
<summary>
Specifies whether this line match is an exact match,
or a context (before or after) match.
</summary>
</member>
<member name="T:Perforce.P4.FileLineMatch">
<summary>
Specifies matching lines in Perforce managed files.
</summary>
</member>
<member name="T:Perforce.P4.FileAction">
<summary>
Describes the pending or completed action related to open,
resolve, or integration for a specific file.
</summary>
</member>
<member name="F:Perforce.P4.FileAction.None">
<summary>
None.
</summary>
</member>
<member name="F:Perforce.P4.FileAction.Add">
<summary>
Opened for add.
</summary>
</member>
<member name="F:Perforce.P4.FileAction.Branch">
<summary>
Opened for branch.
</summary>
</member>
<member name="F:Perforce.P4.FileAction.Edit">
<summary>
Opened for edit.
</summary>
</member>
<member name="F:Perforce.P4.FileAction.Integrate">
<summary>
Opened for integrate.
</summary>
</member>
<member name="F:Perforce.P4.FileAction.Delete">
<summary>
File has been deleted.
</summary>
</member>
<member name="F:Perforce.P4.FileAction.DeleteFrom">
<summary>
file was integrated from partner-file, and partner-file
had been previously deleted.
</summary>
</member>
<member name="F:Perforce.P4.FileAction.DeleteInto">
<summary>
file was integrated into partner-file, and file had been
previously deleted.
</summary>
</member>
<member name="F:Perforce.P4.FileAction.Sync">
<summary>
File has been synced.
</summary>
</member>
<member name="F:Perforce.P4.FileAction.Updated">
<summary>
File has been updated.
</summary>
</member>
<member name="F:Perforce.P4.FileAction.Added">
<summary>
File has been added.
</summary>
</member>
<member name="F:Perforce.P4.FileAction.AddInto">
<summary>
file was integrated into previously nonexistent partner-file,
and partner-file was reopened for add before submission.
</summary>
</member>
<member name="F:Perforce.P4.FileAction.Refreshed">
<summary>
File has been refreshed.
</summary>
</member>
<member name="F:Perforce.P4.FileAction.Ignored">
<summary>
File was integrated from partner-file, accepting yours.
</summary>
</member>
<member name="F:Perforce.P4.FileAction.IgnoredBy">
<summary>
File was integrated into partner-file, accepting yours.
</summary>
</member>
<member name="F:Perforce.P4.FileAction.Abandoned">
<summary>
File has been abandoned.
</summary>
</member>
<member name="F:Perforce.P4.FileAction.EditIgnored">
<summary>
None.
</summary>
</member>
<member name="F:Perforce.P4.FileAction.Move">
<summary>
File is opened for move.
</summary>
</member>
<member name="F:Perforce.P4.FileAction.MoveAdd">
<summary>
File has been added as part of a move.
</summary>
</member>
<member name="F:Perforce.P4.FileAction.MoveDelete">
<summary>
File has been deleted as part of a move.
</summary>
</member>
<member name="F:Perforce.P4.FileAction.MovedFrom">
<summary>
File was integrated from partner-file, accepting theirs
and deleting the original.
</summary>
</member>
<member name="F:Perforce.P4.FileAction.MovedInto">
<summary>
File was integrated into partner-file, accepting merge.
</summary>
</member>
<member name="F:Perforce.P4.FileAction.Unresolved">
<summary>
File has not been resolved.
</summary>
</member>
<member name="F:Perforce.P4.FileAction.CopyFrom">
<summary>
File was integrated from partner-file, accepting theirs.
</summary>
</member>
<member name="F:Perforce.P4.FileAction.CopyInto">
<summary>
File was integrated into partner-file, accepting theirs.
</summary>
</member>
<member name="F:Perforce.P4.FileAction.MergeFrom">
<summary>
File was integrated from partner-file, accepting merge.
</summary>
</member>
<member name="F:Perforce.P4.FileAction.MergeInto">
<summary>
File was integrated into partner-file, accepting merge.
</summary>
</member>
<member name="F:Perforce.P4.FileAction.EditFrom">
<summary>
file was integrated from partner-file, and file was edited
within the p4 resolve process. This allows you to determine
whether the change should ever be integrated back; automated
changes (merge from) needn't be, but original user edits
(edit from) performed during the resolve should be.
</summary>
</member>
<member name="F:Perforce.P4.FileAction.EditInto">
<summary>
File was integrated into partner-file, and partner-file was
reopened for edit before submission.
</summary>
</member>
<member name="F:Perforce.P4.FileAction.Purge">
<summary>
File was purged.
</summary>
</member>
<member name="F:Perforce.P4.FileAction.Import">
<summary>
File was imported.
</summary>
</member>
<member name="F:Perforce.P4.FileAction.BranchFrom">
<summary>
File did not previously exist; it was created as a copy of
partner-file.
</summary>
</member>
<member name="F:Perforce.P4.FileAction.BranchInto">
<summary>
Partner-file did not previously exist; it was created as a
copy of file.
</summary>
</member>
<member name="F:Perforce.P4.FileAction.Reverted">
<summary>
File was reverted.
</summary>
</member>
<member name="T:Perforce.P4.OtherFileUser">
<summary>
Class summarizing the use of this file by another user.
</summary>
</member>
<member name="T:Perforce.P4.OtherUsers">
<summary>
Specifies other users who have a particular file open.
</summary>
</member>
<member name="T:Perforce.P4.FileMetaData">
<summary>
Metadata for a specific file stored in a Perforce repository.
</summary>
</member>
<member name="M:Perforce.P4.FileMetaData.op_Implicit(Perforce.P4.FileSpec)~Perforce.P4.FileMetaData">
<summary>
Cast a FileSpec to FileMetatData
</summary>
<param name="f"></param>
<returns></returns>
</member>
<member name="M:Perforce.P4.FileMetaData.op_Implicit(Perforce.P4.File)~Perforce.P4.FileMetaData">
<summary>
Cast a FileSpec to FileMetatData
</summary>
<param name="f"></param>
<returns></returns>
</member>
<member name="P:Perforce.P4.FileMetaData.DepotPath">
<summary>
The location of the file in the depot
</summary>
</member>
<member name="P:Perforce.P4.FileMetaData.LocalPath">
<summary>
The location of the file in the client's file system,
may be either a ClientPath or a LocalPath
</summary>
</member>
<member name="T:Perforce.P4.FileResolveAction">
<summary>
Describes how, or if a file has been resolved.
</summary>
</member>
<member name="T:Perforce.P4.ResolveAction">
<summary>
The action used in resolving the file.
</summary>
</member>
<member name="T:Perforce.P4.FileResolveRecord">
<summary>
Specifies how file resolve operations were completed or will
potentially be completed.
</summary>
</member>
<member name="T:Perforce.P4.BaseFileType">
<summary>
Flags to define the base file type.
</summary>
</member>
<member name="F:Perforce.P4.BaseFileType.Unspecified">
<summary>
An unspecified base file type.
</summary>
</member>
<member name="F:Perforce.P4.BaseFileType.Text">
<summary>
Client Use: newlines translated.
Server Storage: deltas in RCS format.
</summary>
</member>
<member name="F:Perforce.P4.BaseFileType.Binary">
<summary>
Client Use: raw bytes.
Server Storage: compressed binary.
</summary>
</member>
<member name="F:Perforce.P4.BaseFileType.Symlink">
<summary>
Client Use: symbolic link.
Server Storage: deltas in RCS format.
</summary>
</member>
<member name="F:Perforce.P4.BaseFileType.Apple">
<summary>
Client Use: Mac resource + data.
Server Storage: compressed AppleSingle.
</summary>
</member>
<member name="F:Perforce.P4.BaseFileType.Resource">
<summary>
Client Use: Mac resource fork.
Server Storage: compressed binary.
</summary>
</member>
<member name="F:Perforce.P4.BaseFileType.Unicode">
<summary>
Client Use: newlines translated.
Server Storage: deltas in RCS format
stored as UTF-8.
</summary>
</member>
<member name="F:Perforce.P4.BaseFileType.UTF16">
<summary>
Client Use: newlines translated
client file UTF-16
Server Storage: deltas in RCS format
stored as UTF-8
Files of type utf16 are stored in the depot in UTF-8.
These files are in utf16 in the client workspace.
The automatic type detection requires a BOM be present
at the start of the file. Files without a BOM are
assumed to be in client byte order. When utf16 files
are written to a client, they are written with a BOM
in client byte order.
</summary>
</member>
<member name="F:Perforce.P4.BaseFileType.UTF8">
<summary>
Client Use: newlines translated.
Server Storage: deltas in RCS format
stored as UTF-8.
</summary>
</member>
<member name="T:Perforce.P4.FileTypeModifier">
<summary>
Flags to specify file type modifiers.
</summary>
</member>
<member name="F:Perforce.P4.FileTypeModifier.None">
<summary>
No flags.
</summary>
</member>
<member name="F:Perforce.P4.FileTypeModifier.ModTime">
<summary>
+m always set modtime on client (overrides
client's nomodtime).
</summary>
</member>
<member name="F:Perforce.P4.FileTypeModifier.Writable">
<summary>
+w always writable on client.
</summary>
</member>
<member name="F:Perforce.P4.FileTypeModifier.Exec">
<summary>
+x exec bit set on client.
</summary>
</member>
<member name="F:Perforce.P4.FileTypeModifier.KeywordsAll">
<summary>
+k $Keyword$ expansion of Id, Header, Author
Date, DateTime, Change, File, Revision.
</summary>
</member>
<member name="F:Perforce.P4.FileTypeModifier.KeywordsLimited">
<summary>
+ko $Keyword$ expansion of ID, Header only.
</summary>
</member>
<member name="F:Perforce.P4.FileTypeModifier.ExclusiveOpen">
<summary>
+l exclusive open: disallow multiple opens.
</summary>
</member>
<member name="F:Perforce.P4.FileTypeModifier.CompressedFiles">
<summary>
+C server stores compressed file per revision.
</summary>
</member>
<member name="F:Perforce.P4.FileTypeModifier.RCSDeltaFiles">
<summary>
+D server stores deltas in RCS format.
</summary>
</member>
<member name="F:Perforce.P4.FileTypeModifier.FullRevisions">
<summary>
+F server stores full file per revision.
</summary>
</member>
<member name="F:Perforce.P4.FileTypeModifier.HeadrevOnly">
<summary>
+S server stores only single head revision.
</summary>
</member>
<!-- Badly formed XML comment ignored for member "F:Perforce.P4.FileTypeModifier.NRevsOnly" -->
<member name="F:Perforce.P4.FileTypeModifier.ArchiveTrigger">
<summary>
+X server runs archive trigger to access files
</summary>
</member>
<member name="T:Perforce.P4.FileType">
<summary>
Specifies a Perforce file type for a managed file.
</summary>
</member>
<member name="T:Perforce.P4.P4Server">
<summary>
P4Server
Represents the connection to a Perforce Server using the the P4 Bridge
DLL. It wraps the calls exported by the DLL and transforms the data
types exported by the DLL as native C#.NET data types.
</summary>
<remarks>
This file contains the internal data a methods that are not part of the
public interface
</remarks>
<summary>
P4Server
Represents the connection to a Perforce Server using the the P4 Bridge
DLL. It wraps the calls exported by the DLL and transforms the data
types exported by the DLL as native C#.NET data types.
</summary>
</member>
<member name="F:Perforce.P4.P4Server.isUnicode">
<summary>
Is the server Unicode enabled
</summary>
</member>
<member name="F:Perforce.P4.P4Server.apiLevel">
<summary>
What API level does the server support
</summary>
</member>
<member name="F:Perforce.P4.P4Server.requiresLogin">
<summary>
Does the server require the login command be used
</summary>
</member>
<member name="M:Perforce.P4.P4Server.MarshalPtrToStringUtf16(System.IntPtr)">
<summary>
Marshall a returned pointer as a UTF-16 encoded string
</summary>
<param name="pStr"> Native pointer to the string</param>
<returns>UTF-16 String</returns>
</member>
<member name="M:Perforce.P4.P4Server.MarshalPtrToStringUtf8_Int(System.IntPtr)">
<summary>
Marshall a returned pointer as a UTF-8 encoded string
</summary>
<param name="pStr"> Native pointer to the string</param>
<returns>UTF-16 String</returns>
</member>
<member name="M:Perforce.P4.P4Server.MarshalPtrToStringUtf8(System.IntPtr)">
<summary>
Marshall a returned pointer as a UTF-8 encoded string
</summary>
<param name="pStr"> Native pointer to the string</param>
<returns>UTF-16 String</returns>
</member>
<member name="M:Perforce.P4.P4Server.MarshalPtrToString(System.IntPtr)">
<summary>
Translate a returned string based on the current encoding
</summary>
<param name="pStr"> Native pointer to the string</param>
<returns>UTF-16 String</returns>
</member>
<member name="M:Perforce.P4.P4Server.MarshalPtrToByteArrary(System.IntPtr,System.Int32)">
<summary>
Convert a returned c++ byte pointer (void *) to a byte[]
</summary>
<param name="pData">byte pointer</param>
<param name="byteCnt">byte count</param>
<returns>Converted byte[]</returns>
</member>
<member name="M:Perforce.P4.P4Server.MarshalStringArrayToIntPtrArray(System.String[],System.Int32)">
<summary>
Marshal a String[] into an array of native pointers to strings
in the correct encoding for Unicode enabled servers
</summary>
<param name="args">The args to encode</param>
<param name="argc">Count of args to encode</param>
<returns>Array of IntPtrs to encoded strings</returns>
</member>
<member name="M:Perforce.P4.P4Server.MarshalStringToIntPtr(System.String)">
<summary>
Marshal a String into the correct encoding to pass to a Unicode
enabled server.
</summary>
<param name="arg">String to encode</param>
<returns>IntPtr of the encoded string</returns>
</member>
<member name="M:Perforce.P4.P4Server.MarshalStringToIntPtr(System.Text.Encoding,System.String)">
<summary>
Marshal a String into the correct encoding to pass to a Unicode
enabled server.
</summary>
<param name="arg">String to encode</param>
<returns>IntPtr of the encoded string</returns>
</member>
<member name="F:Perforce.P4.P4Server.pServer">
<summary>
Handle (pointer) to the P4BridgeServer wrapped by this P4Server
</summary>
</member>
<member name="M:Perforce.P4.P4Server.#ctor(System.Boolean)">
<summary>
Internal creator for unit testing other classes
</summary>
<param name="unicode"></param>
</member>
<member name="M:Perforce.P4.P4Server.SetCharacterSet(System.String,System.String)">
<summary>
Set the character set encoding used to pass parameters to a Unicode
enabled server.
</summary>
<remarks>
This is handled automatically after connecting with a P4 server.
</remarks>
<param name="charSet"></param>
<param name="FileCharSet"></param>
</member>
<member name="F:Perforce.P4.P4Server.TaggedOutputCallbackFn_Int">
<summary>
Holds the call back passed to the bridge used to receive the
individual key:value pairs for an object
</summary>
</member>
<member name="F:Perforce.P4.P4Server.pTaggedOutputCallbackFn">
<summary>
Pinned function pointer for the delegate passed to the dll
</summary>
</member>
<member name="F:Perforce.P4.P4Server.CurrentObject">
<summary>
Used to build up an object as its key:value pairs are received
</summary>
</member>
<member name="M:Perforce.P4.P4Server.SetTaggedOutputCallback">
<summary>
Delegate used to send real time tagged results generated by a
command
</summary>
<remarks>
We receive multiple calls for each StrDict object, one for each
key:value pair that will get combined into a single TaggedObject used
to represent an 'object'. This client delegate receives a single
TaggedObject representing the complete object.
</remarks>
</member>
<member name="M:Perforce.P4.P4Server.TaggedOutputCallback_Int(System.UInt32,System.Int32,System.String,System.IntPtr)">
<summary>
Internal callback used to receive the individual Key:Value pair
data for an object
</summary>
We receive multiple calls for each StrDict object, one for each
key:value pair that will get combined into a single TaggedObject used
to represent an 'object'. Object IDs are unique for the objects
returned by a single command, but are not unique across commands.
<remarks>
</remarks>
<param name="objID">Object ID assigned by the bridge</param>
<param name="Key">Key for this entry</param>
<param name="pValue">Value for this entry</param>
</member>
<member name="F:Perforce.P4.P4Server.pErrorCallbackFn">
<summary>
Pinned function pointer for the delegate passed to the dll
</summary>
</member>
<member name="M:Perforce.P4.P4Server.ErrorCallback_Int(System.UInt32,System.Int32,System.Int32,System.IntPtr)">
<summary>
Internal callback used to receive the raw data.
</summary>
The text data pointed to by a char* is marshaled into a String
<remarks>
</remarks>
<param name="severity">Severity level</param>
<param name="pData">char* pointer for error message</param>
</member>
<member name="M:Perforce.P4.P4Server.SetErrorCallback">
<summary>
Set the callback used to return real time Errors.
</summary>
</member>
<member name="F:Perforce.P4.P4Server.InfoResultsCallbackFn_Int">
<summary>
Holds the call back passed to the bridge used to receive the
raw data
</summary>
</member>
<member name="F:Perforce.P4.P4Server.pInfoResultsCallbackFn">
<summary>
Pinned function pointer for the delegate passed to the dll
</summary>
</member>
<member name="M:Perforce.P4.P4Server.InfoResultsCallback_Int(System.UInt32,System.Int32,System.Int32,System.IntPtr)">
<summary>
Internal callback used to receive the raw data.
</summary>
The text data pointed to by a char* is marshaled into a String
<remarks>
</remarks>
<param name="level">message level</param>
<param name="pData">char* pointer to message</param>
</member>
<member name="M:Perforce.P4.P4Server.SetInfoResultsCallback">
<summary>
Set the callback used to return real time info output.
</summary>
</member>
<member name="F:Perforce.P4.P4Server.TextResultsCallbackFn_Int">
<summary>
Holds the call back passed to the bridge used to receive the
raw binary data
</summary>
</member>
<member name="F:Perforce.P4.P4Server.pTextResultsCallbackFn">
<summary>
Pinned function pointer for the delegate passed to the dll
</summary>
</member>
<member name="M:Perforce.P4.P4Server.TextResultsCallback_Int(System.UInt32,System.IntPtr)">
<summary>
Internal callback used to receive the raw text data.
</summary>
The text data pointed to by a char* is marshaled into a String
<remarks>
</remarks>
<param name="pData">char* pointer</param>
</member>
<member name="M:Perforce.P4.P4Server.SetTextResultsCallback">
<summary>
Set the callback used to return real time text output.
</summary>
<remarks>
Far large output, the client may receive multiple callbacks.
Simply concatenate the data to get the complete data.
</remarks>
</member>
<member name="F:Perforce.P4.P4Server.BinaryResultsCallbackFn_Int">
<summary>
Holds the call back passed to the bridge used to receive the
raw binary data
</summary>
</member>
<member name="F:Perforce.P4.P4Server.pBinaryResultsCallbackFn">
<summary>
Pinned function pointer for the delegate passed to the dll
</summary>
</member>
<member name="M:Perforce.P4.P4Server.BinaryResultsCallback_Int(System.UInt32,System.IntPtr,System.Int32)">
<summary>
Internal callback used to receive the raw binary data.
</summary>
The binary data pointed to by a void* is marshaled into a byte[]
<remarks>
</remarks>
<param name="pData">void* pointer</param>
<param name="cnt">Byte count</param>
</member>
<member name="M:Perforce.P4.P4Server.SetBinaryResultsCallback">
<summary>
Set the callback used to return real time binary output.
</summary>
<remarks>
Far large output, the client may receive multiple callbacks.
Simply concatenate the data to get the complete data.
</remarks>
</member>
<member name="F:Perforce.P4.P4Server.PromptCallbackFn_Int">
<summary>
Holds the call back passed to the bridge used to receive input
prompts from the server
</summary>
</member>
<member name="F:Perforce.P4.P4Server.pPromptCallbackFn">
<summary>
Pinned function pointer for the delegate passed to the dll
</summary>
</member>
<member name="F:Perforce.P4.P4Server.ResolveCallbackFn_Int">
<summary>
Holds the call back passed to the bridge used to receive resolve callbacks
with a ClientMerge object from the server
</summary>
</member>
<member name="F:Perforce.P4.P4Server.ResolveCallbackFn">
<summary>
Pinned function pointer for the delegate passed to the dll
</summary>
</member>
<member name="F:Perforce.P4.P4Server.ResolveACallbackFn_Int">
<summary>
Holds the call back passed to the bridge used to receive resolve callbacks
with a ClientResolve object from the server
</summary>
</member>
<member name="F:Perforce.P4.P4Server.ResolveACallbackFn">
<summary>
Pinned function pointer for the delegate passed to the dll
</summary>
</member>
<member name="M:Perforce.P4.P4Server.#ctor(System.String,System.String,System.String,System.String)">
<summary>
Create a P4BridgeServer used to connect to the specified P4Server
</summary>
<param name="server">Host:port for the P4 server.</param>
<param name="user">User name for the login.
Can be null/blank if only running commands that do not require
a login.</param>
<param name="pass">Password for the login. Can be null/blank if
only running commands that do not require a login.</param>
<param name="ws_client">Workspace (client) to be used by the
connection. Can be null/blank if only running commands that do
not require a login.</param>
</member>
<member name="M:Perforce.P4.P4Server.#ctor(System.String)">
<summary>
Create a P4BridgeServer using the PUC specified by the environment
or a p4config file if one exists.
</summary>
<param name="cwd">Current working Directory. Can be null/blank if
not connecting to the Perforce server using a P4Config file.</param>
</member>
<member name="M:Perforce.P4.P4Server.#ctor(System.String,System.String,System.String,System.String,System.String)">
<summary>
Create a P4BridgeServer used to connect to the specified P4Server
</summary>
<param name="server">Host:port for the P4 server.</param>
<param name="user">User name for the login.
Can be null/blank if only running commands that do not require
a login.</param>
<param name="pass">Password for the login. Can be null/blank if
only running commands that do not require a login.</param>
<param name="ws_client">Workspace (client) to be used by the
connection. Can be null/blank if only running commands that do
not require a login.</param>
<param name="cwd">Current working Directory. Can be null/blank if
not connecting to the Perforce server using a P4Config file.</param>
</member>
<member name="M:Perforce.P4.P4Server.#ctor(System.String,System.String,System.String,System.String,System.String,System.String,System.String)">
<summary>
Create a P4BridgeServer used to connect to the specified P4Server
</summary>
<param name="server">Host:port for the P4 server.</param>
<param name="user">User name for the login.
Can be null/blank if only running commands that do not require
a login.</param>
<param name="pass">Password for the login. Can be null/blank if
only running commands that do not require a login.</param>
<param name="ws_client">Workspace (client) to be used by the
connection. Can be null/blank if only running commands that do
not require a login.</param>
</member>
<member name="M:Perforce.P4.P4Server.Login(System.String,Perforce.P4.StringList)">
<summary>
Run a login command on the server
</summary>
<param name="password">User's password</param>
<returns>Success/Failure</returns>
<remarks>
If the server requires a login (security level >= 3), this will
prompt for the password. If login is not required, the command will
just return with a result saying that login is not required.
</remarks>
</member>
<member name="M:Perforce.P4.P4Server.Logout(Perforce.P4.StringList)">
<summary>
Run a logout command on the server
</summary>
<param name="options">The -a flag invalidates the ticket on the server.</param>
<returns>Success/Failure</returns>
<remarks>
If the server requires a login (security level >= 3), this will
logout the user and remove the local ticket.
</remarks>
</member>
<member name="M:Perforce.P4.P4Server.Finalize">
<summary>
Finalizer
</summary>
</member>
<member name="M:Perforce.P4.P4Server.Dispose">
<summary>
For IDispose
</summary>
</member>
<member name="M:Perforce.P4.P4Server.Reconnect">
<summary>
Reconnect to the server in the event the connection is lost
</summary>
</member>
<member name="M:Perforce.P4.P4Server.Close">
<summary>
Close the connection to a P4 Server
</summary>
<remarks>
Called by the Dispose() method
</remarks>
</member>
<member name="F:Perforce.P4.P4Server.KeepAliveDelay">
<summary>
Time for a command to run before allowing the client/user to cancel;
</summary>
</member>
<member name="M:Perforce.P4.P4Server.RunCommand(System.String,System.UInt32,System.Boolean,System.String[],System.Int32)">
<summary>
Run a P4 command on the P4 Server
</summary>
<remarks>
If the command fails, the error output will contain one or more
errors generated by the P4 server.
</remarks>
<param name="cmd">Command code</param>
<param name="tagged">Use tagged output for the results</param>
<param name="args">Arguments for the command</param>
<param name="argc">Argument count</param>
<returns>Success/Failure</returns>
</member>
<member name="M:Perforce.P4.P4Server.CancelCommand(System.UInt32)">
<summary>
Cancel a running command
</summary>
<param name="CmdId">Unique Id for the run of the command</param>
</member>
<member name="M:Perforce.P4.P4Server.ReleaseConnection(System.UInt32)">
<summary>
Release the UI created for a command after it has been completed
</summary>
<param name="cmdId">Unique Id for the run of the command</param>
</member>
<member name="M:Perforce.P4.P4Server.ReleaseConnection(System.UInt32,System.DateTime)">
<summary>
Release the UI created for a command after it has been completed
</summary>
<param name="cmdId">Unique Id for the run of the command</param>
</member>
<member name="M:Perforce.P4.P4Server.FreeConnections">
<summary>
Free the UI created for a command after it is no longer needed
</summary>
<param name="cmdId">Unique Id for the run of the command</param>
</member>
<member name="M:Perforce.P4.P4Server.GetTaggedOutput(System.UInt32)">
<summary>
Get the tagged output generated by a command
</summary>
<returns>A list of TaggedObjects comprising the tagged output.
</returns>
</member>
<member name="F:Perforce.P4.P4Server.ErrorCallbackFn_Int">
<summary>
Holds the call back passed to the bridge used to receive the
raw data
</summary>
</member>
<member name="M:Perforce.P4.P4Server.GetErrorResults(System.UInt32)">
<summary>
Get a list of errors (if any) generated by a command
</summary>
<returns>A list of P4ClientErrors, null if no errors</returns>
</member>
<member name="M:Perforce.P4.P4Server.GetInfoResults(System.UInt32)">
<summary>
Get the information messages generated by the previous command
</summary>
<remarks>
Each message is formatted as follows
l:Message text
where l is a single digit representing the message level
</remarks>
<returns>List of messages</returns>
</member>
<member name="M:Perforce.P4.P4Server.GetTextResults(System.UInt32)">
<summary>
Get the complete text results for the last command
</summary>
<returns></returns>
</member>
<member name="M:Perforce.P4.P4Server.GetBinaryResults(System.UInt32)">
<summary>
Get the complete binary results for the last command
</summary>
<returns>The binary data</returns>
</member>
<member name="M:Perforce.P4.P4Server.EchoCommand(System.String,Perforce.P4.StringList)">
<summary>
Broadcast a the command line (cmd and args) on the CommandEcho event
</summary>
<remarks>
Used to echo an executed command line back to the client
</remarks>
<param name="cmd">The P4 command.</param>
<param name="args">The flags and parameters for the command.</param>
</member>
<member name="M:Perforce.P4.P4Server.EchoCommand(System.String)">
<summary>
Broadcast a string on the CommandEcho event
</summary>
<remarks>
Used to echo command data back to the client
</remarks>
<param name="str">The string.</param>
</member>
<member name="M:Perforce.P4.P4Server.SetDataSet(System.UInt32,System.String)">
<summary>
The data set for use by a command
</summary>
<remarks>
If a command requires data not passed on the command line, such as
a client spec, it is passed to the P$ server by setting the data
set in the P4 api.
</remarks>
</member>
<member name="F:Perforce.P4.P4Server.PromptHandler">
<summary>
Delegate used to process prompts for input from the server.
</summary>
</member>
<member name="F:Perforce.P4.P4Server.ResolveHandler">
<summary>
Delegate used to provide a custom handler for Resolve callbacks passing a ClientMerge object from the p4api.
</summary>
</member>
<member name="F:Perforce.P4.P4Server.ResolveAHandler">
<summary>
Delegate used to provide a custom handler for Resolve callbacks passing a ClientResolve object from the p4api.
</summary>
</member>
<member name="M:Perforce.P4.P4Server.SetConnectionData(System.String,System.String,System.String,System.String)">
<summary>
The parameters used by the connection
</summary>
<remarks>
The properties, client, port, user, and password,
represent the criteria used to connect to a P4 server. If one or
more is changed, the bridge will drop the current connection if any
and attempt to connect to the (possibly different) P4 server when
the next command is executed. If it is desirable to validate the
connection, execute a command.
</remarks>
</member>
<member name="M:Perforce.P4.P4Server.GetConfig(System.String)">
<summary>
The config file that will be used by a given directory
</summary>
</member>
<member name="M:Perforce.P4.P4Server.Get(System.String)">
<summary>
Get an environment setting used by the server, such as user, client, ..
</summary>
<param name="var">The name of the environment varible</param>
<returns></returns>
</member>
<member name="M:Perforce.P4.P4Server.Set(System.String,System.String)">
<summary>
Set an environment setting used by the server, such as user, client, ..
</summary>
<param name="var">The name of the environment variable</param>
<param name="val">The new value for the environment variable</param>
<returns></returns>
</member>
<member name="M:Perforce.P4.P4Server.IsIgnored(System.String)">
<summary>
Use the C++ API to determine if a file will be ignored
</summary>
<param name="path">The local path of the file</param>
<returns>true if the file will be ignored</returns>
</member>
<member name="M:Perforce.P4.P4Server.GetTicketFile">
<summary>
Use the C++ API to determine the path of the ticket file
</summary>
<returns>The path for the ticket file</returns>
</member>
<member name="M:Perforce.P4.P4Server.GetTicket(System.String,System.String)">
<summary>
Use the C++ API to find an existing ticket if a file will be ignored
</summary>
<param name="port">server:port for the connection</param>
<param name="user">user name for the connection</param>
<returns>The existing ticket if any</returns>
</member>
<member name="M:Perforce.P4.P4Server.GetTicketFileCredential(System.String,System.String)">
<summary>
Use the C++ API to find an existing ticket if a file will be ignored
</summary>
<param name="port">server:port for the connection</param>
<param name="user">user name for the connection</param>
<returns>The existing ticket if any</returns>
</member>
<member name="P:Perforce.P4.P4Server.LastResults">
<summary>
The results of the last command executed on this thread
</summary>
</member>
<member name="P:Perforce.P4.P4Server.Version">
<summary>
Get the version of the p4.net assembly
</summary>
</member>
<member name="P:Perforce.P4.P4Server.ConnectionErrorInt">
<summary>
Get the error message generated by the previous connection (if any)
</summary>
</member>
<member name="P:Perforce.P4.P4Server.ConnectionError">
<summary>
Get the error message generated by the previous connection (if any)
from the bridge dll.
</summary>
</member>
<member name="P:Perforce.P4.P4Server.UseUnicode">
<summary>
Need to use Unicode when marshalling to/from the P4 server
</summary>
</member>
<member name="P:Perforce.P4.P4Server.ApiLevel">
<summary>
What API level does the server support
</summary>
</member>
<member name="P:Perforce.P4.P4Server.ReqiresLogin">
<summary>
The server requires a client to use the login command to pass credentials.
</summary>
</member>
<member name="E:Perforce.P4.P4Server.TaggedOutputReceived">
<summary>
Event to broadcast tagged output
</summary>
</member>
<member name="E:Perforce.P4.P4Server.ErrorReceived">
<summary>
Broadcast errors received
</summary>
</member>
<member name="E:Perforce.P4.P4Server.InfoResultsReceived">
<summary>
Broadcast event for info results
</summary>
</member>
<member name="E:Perforce.P4.P4Server.TextResultsReceived">
<summary>
Broadcast event for text results
</summary>
</member>
<member name="E:Perforce.P4.P4Server.BinaryResultsReceived">
<summary>
Broadcast event for binary data
</summary>
</member>
<member name="E:Perforce.P4.P4Server.CommandEcho">
<summary>
Broadcast event for text results
</summary>
</member>
<member name="P:Perforce.P4.P4Server.Client">
<summary>
The client workspace used by the connection
</summary>
<remarks>
The properties, client, port, user, and password,
represent the criteria used to connect to a P4 server. If one or
more is changed, the bridge will drop the current connection if any
and attempt to connect to the (possibly different) P4 server when
the next command is executed. If it is desirable to validate the
connection, execute a command.
</remarks>
</member>
<member name="P:Perforce.P4.P4Server.User">
<summary>
The user name used by the connection
</summary>
<remarks>
The properties, client, port, user, and password,
represent the criteria used to connect to a P4 server. If one or
more is changed, the bridge will drop the current connection if any
and attempt to connect to the (possibly different) P4 server when
the next command is executed. If it is desirable to validate the
connection, execute a command.
</remarks>
</member>
<member name="P:Perforce.P4.P4Server.Port">
<summary>
The hostname:port used by the connection
</summary>
<remarks>
The properties, client, port, user, and password,
represent the criteria used to connect to a P4 server. If one or
more is changed, the bridge will drop the current connection if any
and attempt to connect to the (possibly different) P4 server when
the next command is executed. If it is desirable to validate the
connection, execute a command.
</remarks>
</member>
<member name="P:Perforce.P4.P4Server.Password">
<summary>
The user's password used by the connection
</summary>
<remarks>
The properties, client, port, user, and password,
represent the criteria used to connect to a P4 server. If one or
more is changed, the bridge will drop the current connection if any
and attempt to connect to the (possibly different) P4 server when
the next command is executed. If it is desirable to validate the
connection, execute a command.
</remarks>
</member>
<member name="P:Perforce.P4.P4Server.ProgramName">
<summary>
The program name used by the connection
</summary>
<remarks>
The program name and version are recorded in the server logs when
accessed by the client
</remarks>
</member>
<member name="P:Perforce.P4.P4Server.ProgramVersion">
<summary>
The program version used by the connection
</summary>
<remarks>
The program name and version are recorded in the server logs when
accessed by the client
</remarks>
</member>
<member name="P:Perforce.P4.P4Server.CurrentWorkingDirectory">
<summary>
The current working directory (cwd) used by the p4 server
</summary>
<remarks>
The properties, client, port, user, and password,
represent the criteria used to connect to a P4 server. If one or
more is changed, the bridge will drop the current connection if any
and attempt to connect to the (possibly different) P4 server when
the next command is executed. If it is desirable to validate the
connection, execute a command.
</remarks>
</member>
<member name="P:Perforce.P4.P4Server.CharacterSet">
<summary>
The character set used by the connection
</summary>
<remarks>
The character set used to connect to Unicode servers is set by the
bridge dll automatically (possibly overridden by P4CHARSET) based
on the current Windows code page.
</remarks>
</member>
<member name="P:Perforce.P4.P4Server.Config">
<summary>
The config file used by the connection
</summary>
</member>
<member name="T:Perforce.P4.P4Server.P4Encoding">
<summary>
P4Encoding
How do we encode Unicode UTF-16 strings, the .NET internal format
before sending them to the bridge dll?
</summary>
</member>
<member name="T:Perforce.P4.P4Server.TaggedOutputDelegate">
<summary>
Delegate used to send tagged output as it is generated.
</summary>
<remarks>
This delegate will send a complete object after all of its fields
have been received by the callback from the bridge dll.
</remarks>
<param name="ObjId"></param>
<param name="Obj"></param>
</member>
<member name="T:Perforce.P4.P4Server.ErrorDelegate">
<summary>
Delegate used to send errors as they are generated.
</summary>
<remarks>
This delegate will send a block of data for each call received by
the callback from the bridge dll.
</remarks>
<param name="cmdId">Command Id of the command causing the error</param>
<param name="severity">Severity of the error</param>
<param name="errorNumber">Error number for the error</param>
<param name="data">Error message</param>
</member>
<member name="T:Perforce.P4.P4Server.InfoResultsDelegate">
<summary>
Delegate used to send Info Results as they are generated.
</summary>
<remarks>
This delegate will send a block of data for each call received by
the callback from the bridge dll.
</remarks>
<param name="level">Server supplied message level</param>
<param name="data">Server supplied message data</param>
</member>
<member name="T:Perforce.P4.P4Server.TextResultsDelegate">
<summary>
Delegate used to send Text Results as they are generated.
</summary>
<remarks>
This delegate will send a block of data for each call received by
the callback from the bridge dll.
</remarks>
<param name="data">Text results generated by the command</param>
</member>
<member name="T:Perforce.P4.P4Server.BinaryResultsDelegate">
<summary>
Delegate used to send binary output as it is generated.
</summary>
<remarks>
This delegate will send a block of data for each call received by
the callback from the bridge dll.
</remarks>
<param name="data">Binary data generated by a command</param>
</member>
<member name="T:Perforce.P4.P4Server.CommandEchoDelegate">
<summary>
Delegate used to commands as they are executed.
</summary>
<param name="data">Command line executed by the command</param>
</member>
<member name="T:Perforce.P4.P4Server.PromptHandlerDelegate">
<summary>
Delegate used to provide a custom handler for input prompts from the p4api.
</summary>
<param name="msg"></param>
<param name="displayText"></param>
<returns></returns>
</member>
<member name="T:Perforce.P4.P4Server.ResolveHandlerDelegate">
<summary>
Delegate used to provide a custom handler for Resolve callbacks passing a ClientMerge object from the p4api.
</summary>
<returns></returns>
</member>
<member name="T:Perforce.P4.P4Server.ResolveAHandlerDelegate">
<summary>
Delegate used to provide a custom handler for Resolve callbacks passing a ClientResolve object from the p4api.
</summary>
<returns></returns>
</member>
<member name="T:Perforce.P4.LogFile">
<summary>
Generic interface used to an event logger. In short, messages are
logged by:
1) Level. The lower the level, the more sever the level,
0 fatal
1 error
2 warning
3 information
4+ debugging messages
2) Source. A string specifying the origin of the message, ie P4Server
3) Message. The text of the message.
</summary>
</member>
<member name="T:Perforce.P4.IKeepAlive">
<summary>
Allows a client to monitor the execution of a command. It allow the client to
cancel the command if it takes to long to complete or display a UI to allow the
user to cancel the command.
</summary>
</member>
<member name="M:Perforce.P4.IKeepAlive.StartQueryCancel(Perforce.P4.P4Server,System.UInt32,System.Threading.Thread,System.String)">
<summary>
A command is starting
</summary>
<param name="server">Server running the command</param>
<param name="cmdId">CmdId of the command</param>
<param name="cmdLine">Command Line for the command for display purposes</param>
<returns></returns>
</member>
<member name="M:Perforce.P4.IKeepAlive.CommandCompleted(System.UInt32)">
<summary>
The command has completed dismiss any UI or timeouts
</summary>
<param name="cmdId">CmdId of the command that completed</param>
<remarks>
Note, it is OK for the API might send this multiple times with the,
same cmdId to ensure that any UI displayed by the client iss dismissed.
</remarks>
</member>
<member name="T:Perforce.P4.P4CallBacks">
<summary>
Class wrapper for the definitions of delegates required to model the
callbacks from the bridge dll.
</summary>
</member>
<member name="T:Perforce.P4.P4CallBacks.LogMessageDelegate">
<summary>
Delegate definition for the Logging callback from the dll.
</summary>
<param name="log_level">Log Level Lower values are more serious
than higher values.</param>
<param name="file">Name of the cpp file containing the call.
</param>
<param name="line">Line number in the cpp file of the call.</param>
<param name="message">Descriptive message to be logged.</param>
</member>
<member name="T:Perforce.P4.P4CallBacks.TaggedOutputDelegate">
<summary>
Delegate definition for the tagged output delegate.
</summary>
<remarks>
Each call of this delegate by the bridge provides a single Key:Value
pair for the current object. When all the Key:Value pairs for an
object have been sent, the bridge will make one final call with null
for the values of the key and value to signify it is complete. Each
object generated by a command will have an object ID that unique for
that command.
</remarks>
<param name="cmdID">Id if the command making the callback</param>
<param name="objID">Object ID for the object</param>
<param name="key">The Key of this Key:Value pair</param>
<param name="value">The Key of this Key:Value pair</param>
</member>
<member name="T:Perforce.P4.P4CallBacks.ErrorDelegate">
<summary>
Delegate definition for the error callback.
</summary>
<param name="cmdID">Id if the command making the callback</param>
<param name="severity">Severity of the error</param>
<param name="info">Error Message</param>
</member>
<member name="T:Perforce.P4.P4CallBacks.InfoResultsDelegate">
<summary>
Delegate definition for the info results callback.
</summary>
<remarks>
The "info" results generally are the output of commands that are run
<b>not</b> using tagged protocol
</remarks>
<param name="cmdID">Id of the command making the callback</param>
<param name="msgID">Unique Id of the message from the server</param>
<param name="level"></param>
<param name="info"></param>
</member>
<member name="T:Perforce.P4.P4CallBacks.TextResultsDelegate">
<summary>
Delegate definition for the text results callback.
</summary>
<remarks>
If this callback is used, the text output generated by a command
will be delivered by one or more call to the supplied delegate.
It multiple calls are made, the entire text is obtained by
concatenating the text from each call.
</remarks>
<param name="cmdID">Id if the command making the callback</param>
<param name="info">Text output produced by the command</param>
</member>
<member name="T:Perforce.P4.P4CallBacks.BinaryResultsDelegate">
<summary>
Delegate definition for the binary results callback.
</summary>
<remarks>
If this callback is used, the binary output generated by a command
will be delivered by one or more call to the supplied delegate.
It multiple calls are made, the entire output is obtained by
concatenating the data from each call.
</remarks>
<param name="cmdID">Id if the command making the callback</param>
<param name="data">Binary data generated by the command</param>
<param name="count">The size in bytes of the data</param>
</member>
<member name="T:Perforce.P4.P4CallBacks.PromptDelegate">
<summary>
Delegate definition for the prompt callback.
</summary>
<param name="cmdID">Id if the command making the callback</param>
<param name="msg">Prompt message from the server</param>
<param name="rspBuf">Character buffer to receive the response</param>
<param name="bufSz">Size of the buffer</param>
<param name="dispayText">Display flog</param>
</member>
<member name="T:Perforce.P4.P4CallBacks.ResolveDelegate">
<summary>
Delegate definition for the Resolve callback passing a CLientMerge object.
</summary>
<param name="Merger">P4ClientMerge used to handle the resolve</param>
<returns>Resolve result</returns>
</member>
<member name="T:Perforce.P4.P4CallBacks.ResolveADelegate">
<summary>
Delegate definition for the Resolve callback passing a CLientResolve object.
</summary>
<param name="cmdID">Id if the command making the callback</param>
<param name="Resolver">P4ClientReslove used to handle the resolve</param>
<param name="preview">Preview only</param>
<returns>Resolve result</returns>
</member>
<member name="T:Perforce.P4.P4Bridge">
<summary>
Class containing the DLL imports for the P4Bridge DLL.
</summary>
</member>
<member name="M:Perforce.P4.P4Bridge.ConnectA(System.String,System.String,System.String,System.String,Perforce.P4.P4CallBacks.LogMessageDelegate)">
<summary>
Create a new P4BridgeServer in the DLL and connect to the
specified P4 Server.
</summary>
<param name="server">Host:port for the P4 server.</param>
<param name="user">User name for the login.
Can be null/blank if only running commands that do not require
a login.</param>
<param name="password">Password for the login. Can be null/blank if
only running commands that do not require a login.</param>
<param name="ws_client">Workspace (client) to be used by the
connection. Can be null/blank if only running commands that do
not require a login.</param>
<param name="logfn">Function pointer for the logging callback. Can
be null if logging is not desired.</param>
<returns>Handle (pointer) to the P4BridgeServer</returns>
</member>
<member name="M:Perforce.P4.P4Bridge.ConnectW(System.String,System.IntPtr,System.IntPtr,System.IntPtr,System.IntPtr)">
<summary>
Create a new P4BridgeServer in the DLL and connect to the
specified P4 Server.
</summary>
<param name="server">Host:port for the P4 server.</param>
<param name="user">User name for the login.
Can be null/blank if only running commands that do not require
a login.</param>
<param name="password">Password for the login. Can be null/blank if
only running commands that do not require a login.</param>
<param name="ws_client">Workspace (client) to be used by the
connection. Can be null/blank if only running commands that do
not require a login.</param>
<param name="logfn">Function pointer for the logging callback. Can
be null if logging is not desired.</param>
<returns>Handle (pointer) to the P4BridgeServer</returns>
</member>
<member name="M:Perforce.P4.P4Bridge.TrustedConnectA(System.String,System.String,System.String,System.String,System.String,System.String,Perforce.P4.P4CallBacks.LogMessageDelegate)">
<summary>
Create a new P4BridgeServer in the DLL and connect to the
specified P4 Server.
</summary>
<param name="server">Host:port for the P4 server.</param>
<param name="user">User name for the login.
Can be null/blank if only running commands that do not require
a login.</param>
<param name="password">Password for the login. Can be null/blank if
only running commands that do not require a login.</param>
<param name="ws_client">Workspace (client) to be used by the
connection. Can be null/blank if only running commands that do
not require a login.</param>
<param name="trust_flag">Flag to pass to the trust command.</param>
<param name="fingerprint">Fingerprint to pass to the trust
command.</param>
<param name="logfn">Function pointer for the logging callback. Can
be null if logging is not desired.</param>
<returns>Handle (pointer) to the P4BridgeServer</returns>
</member>
<member name="M:Perforce.P4.P4Bridge.TrustedConnectW(System.String,System.IntPtr,System.IntPtr,System.IntPtr,System.String,System.String,System.IntPtr)">
<summary>
Create a new P4BridgeServer in the DLL and connect to the
specified P4 Server.
</summary>
<param name="server">Host:port for the P4 server.</param>
<param name="user">User name for the login.
Can be null/blank if only running commands that do not require
a login.</param>
<param name="password">Password for the login. Can be null/blank if
only running commands that do not require a login.</param>
<param name="ws_client">Workspace (client) to be used by the
connection. Can be null/blank if only running commands that do
not require a login.</param>
<param name="trust_flag">Flag to pass to the trust command.</param>
<param name="fingerprint">Fingerprint to pass to the trust
command.</param>
<param name="logfn">Function pointer for the logging callback. Can
be null if logging is not desired.</param>
<returns>Handle (pointer) to the P4BridgeServer</returns>
</member>
<member name="M:Perforce.P4.P4Bridge.GetConnectionError">
<summary>
Get the error message generated by the previous connection (if any)
</summary>
<returns>Error Message. Null if no error occurred</returns>
</member>
<member name="M:Perforce.P4.P4Bridge.SetCharacterSet(System.IntPtr,System.String,System.String)">
<summary>
Sets the character set used by the P4Bridge server if connection is
to Unicode enabled server.
</summary>
<param name="pServer">Handle of the P4BridgeServer</param>
<param name="charSet">Character set to use for Unicode data
exchanged with the P4 Server</param>
<param name="FileCharSet">Character set to use for files
stored in
the client' host file space</param>
<returns>null if no error, otherwise a pointer to an error
message.</returns>
</member>
<member name="M:Perforce.P4.P4Bridge.Disconnect(System.IntPtr)">
<summary>
Close the connection
</summary>
<param name="pServer">P4BridgeServer Handle</param>
</member>
<member name="M:Perforce.P4.P4Bridge.CloseConnection(System.IntPtr)">
<summary>
Close the connection
</summary>
<param name="pServer">P4BridgeServer Handle</param>
</member>
<member name="M:Perforce.P4.P4Bridge.IsUnicode(System.IntPtr)">
<summary>
Check if the server supports Unicode
</summary>
<remarks>
Note: Is set during connection so is valid immediately after
Connect() successfully completes.
</remarks>
<param name="pServer">P4BridgeServer Handle</param>
<returns></returns>
</member>
<member name="M:Perforce.P4.P4Bridge.APILevel(System.IntPtr)">
<summary>
Check to see what API level the server supports
</summary>
<remarks>
Note: Is set during connection so is valid immediately after
Connect() successfully completes.
</remarks>
<param name="pServer">P4BridgeServer Handle</param>
<returns></returns>
</member>
<member name="M:Perforce.P4.P4Bridge.UseLogin(System.IntPtr)">
<summary>
Check if the server requires the login command be used
</summary>
<remarks>
Note: Is set during connection so is valid immediately after
Connect() successfully completes.
</remarks>
<param name="pServer">P4BridgeServer Handle</param>
<returns></returns>
</member>
<member name="M:Perforce.P4.P4Bridge.SupportsExtSubmit(System.IntPtr)">
<summary>
Check if the server supports extended submit options (2006.2 higher)
</summary>
<remarks>
Note: Is set during connection so is valid immediately after
Connect() successfully completes.
</remarks>
<param name="pServer">P4BridgeServer Handle</param>
<returns></returns>
</member>
<member name="M:Perforce.P4.P4Bridge.RunCommandA(System.IntPtr,System.String,System.UInt32,System.Boolean,System.String[],System.Int32)">
<summary>
Run a command on the P4 Server
</summary>
<remarks>
The A version is used to pass ASCII parameters
</remarks>
<param name="pServer">P4BridgeServer Handle</param>
<param name="cmd">Command. i.e "fstat"</param>
<param name="cmdId">Unique Id for the run of the command</param>
<param name="tagged">If true, use tagged protocol the receive the
output</param>
<param name="args">Arguments for the command</param>
<param name="argc">Argument count</param>
<returns></returns>
</member>
<member name="M:Perforce.P4.P4Bridge.RunCommandW(System.IntPtr,System.String,System.UInt32,System.Boolean,System.IntPtr[],System.Int32)">
<summary>
Run a command on the P4 Server
</summary>
<remarks>
The W version is used to pass Unicode (wide) parameters
</remarks>
<param name="pServer">P4BridgeServer Handle</param>
<param name="cmd">Command. i.e "fstat"</param>
<param name="cmdId">Unique Id for the run of the command</param>
<param name="tagged">If true, use tagged protocol the receive the
output</param>
<param name="args">Arguments for the command</param>
<param name="argc">Argument count</param>
<returns></returns>
</member>
<member name="M:Perforce.P4.P4Bridge.CancelCommand(System.IntPtr,System.UInt32)">
<summary>
Cancel a running command
</summary>
<param name="pServer">P4BridgeServer Handle</param>
<param name="cmdId">Unique Id for the run of the command</param>
</member>
<member name="M:Perforce.P4.P4Bridge.ReleaseConnection(System.IntPtr,System.UInt32,System.UInt64)">
<summary>
Release the UI created for a command after it has been completed
</summary>
<param name="pServer">P4BridgeServer Handle</param>
<param name="cmdId">Unique Id for the run of the command</param>
</member>
<member name="M:Perforce.P4.P4Bridge.FreeConnections(System.IntPtr,System.UInt64)">
<summary>
Free the connection created for a command and disconnect from
the server
</summary>
<param name="pServer">P4BridgeServer Handle</param>
<param name="cmdId">Unique Id for the run of the command</param>
</member>
<member name="M:Perforce.P4.P4Bridge.SetTaggedOutputCallbackFn(System.IntPtr,System.IntPtr)">
<summary>
Set the callback for tagged output
</summary>
<param name="pServer">P4BridgeServer Handle</param>
<param name="pNew">Pinned pointer to the callback delegate</param>
</member>
<member name="M:Perforce.P4.P4Bridge.SetErrorCallbackFn(System.IntPtr,System.IntPtr)">
<summary>
Set the callback for error output
</summary>
<param name="pServer">P4BridgeServer Handle</param>
<param name="pNew">Pinned pointer to the callback delegate</param>
</member>
<member name="M:Perforce.P4.P4Bridge.SetInfoResultsCallbackFn(System.IntPtr,System.IntPtr)">
<summary>
Set the callback for Info (non tagged) output
</summary>
<param name="pServer">P4BridgeServer Handle</param>
<param name="pcb">Pinned pointer to the callback delegate</param>
</member>
<member name="M:Perforce.P4.P4Bridge.SetTextResultsCallbackFn(System.IntPtr,System.IntPtr)">
<summary>
Set the callback for text output
</summary>
<param name="pServer">P4BridgeServer Handle</param>
<param name="pNew">Pinned pointer to the callback delegate</param>
</member>
<member name="M:Perforce.P4.P4Bridge.SetBinaryResultsCallbackFn(System.IntPtr,System.IntPtr)">
<summary>
Set the callback for binary output
</summary>
<param name="pServer">P4BridgeServer Handle</param>
<param name="pNew">Pinned pointer to the callback delegate</param>
</member>
<member name="M:Perforce.P4.P4Bridge.SetPromptCallbackFn(System.IntPtr,System.IntPtr)">
<summary>
Set the call back to receive input prompts from the sever
</summary>
<param name="pServer">P4BridgeServer Handle</param>
<param name="pNew">Pinned pointer to the callback delegate</param>
</member>
<member name="M:Perforce.P4.P4Bridge.GetTaggedOutputCount(System.IntPtr,System.UInt32)">
<summary>
Get the number of entries in the tagged output for the last command
</summary>
<param name="pServer">P4BridgeServer Handle</param>
<returns>StrDictListIterator Handle (pointer) used to read the data</returns>
</member>
<member name="M:Perforce.P4.P4Bridge.GetTaggedOutput(System.IntPtr,System.UInt32)">
<summary>
Get the tagged output for the last command
</summary>
<param name="pServer">P4BridgeServer Handle</param>
<returns>StrDictListIterator Handle (pointer) used to read the data</returns>
</member>
<member name="M:Perforce.P4.P4Bridge.GetErrorResults(System.IntPtr,System.UInt32)">
<summary>
Get the error output for the last command
</summary>
<param name="pServer">P4BridgeServer Handle</param>
<returns>P4ClientErrorList Handle (pointer) used to read the data</returns>
</member>
<member name="M:Perforce.P4.P4Bridge.GetInfoResultsCount(System.IntPtr,System.UInt32)">
<summary>
Get the info output for the last command
</summary>
<param name="pServer">P4BridgeServer Handle</param>
<returns>Handle (pointer) to the string data</returns>
</member>
<member name="M:Perforce.P4.P4Bridge.GetInfoResults(System.IntPtr,System.UInt32)">
<summary>
Get the info output for the last command
</summary>
<param name="pServer">P4BridgeServer Handle</param>
<returns>Handle (pointer) to the string data</returns>
</member>
<member name="M:Perforce.P4.P4Bridge.GetTextResults(System.IntPtr,System.UInt32)">
<summary>
Get the text output for the last command
</summary>
<param name="pServer">P4BridgeServer Handle</param>
<returns>Handle (pointer) to the string data</returns>
</member>
<member name="M:Perforce.P4.P4Bridge.GetBinaryResultsCount(System.IntPtr,System.UInt32)">
<summary>
Get the byte count for the binary output for the last command
</summary>
<param name="pServer">P4BridgeServer Handle</param>
<returns>Handle (pointer) to the data bytes</returns>
</member>
<member name="M:Perforce.P4.P4Bridge.GetBinaryResults(System.IntPtr,System.UInt32)">
<summary>
Get the binary output for the last command
</summary>
<param name="pServer">P4BridgeServer Handle</param>
<returns>Handle (pointer) to the data bytes</returns>
</member>
<member name="M:Perforce.P4.P4Bridge.SetDataSetW(System.IntPtr,System.UInt32,System.IntPtr)">
<summary>
Set the data set using Unicode data
</summary>
<remarks>
The encoding should match that set by SetCharacterSet()
</remarks>
<param name="pServer">P4BridgeServer Handle</param>
<param name="data">New Unicode data set</param>
</member>
<member name="M:Perforce.P4.P4Bridge.SetDataSetA(System.IntPtr,System.UInt32,System.String)">
<summary>
Set the data set using Unicode data
</summary>
<param name="pServer">P4BridgeServer Handle</param>
<param name="data">New ASCII data set</param>
</member>
<member name="M:Perforce.P4.P4Bridge.GetDataSet(System.IntPtr,System.UInt32)">
<summary>
Read the data set
</summary>
<remarks>
The data will be encoded in ASII or Unicode, depending on the
server configuration and character set set previously with
SetCharacterSet().
</remarks>
<param name="pServer">P4BridgeServer Handle</param>
<returns>The data in the data set</returns>
</member>
<member name="M:Perforce.P4.P4Bridge.set_connectionW(System.IntPtr,System.IntPtr,System.IntPtr,System.IntPtr,System.IntPtr)">
<summary>
Set the connection parameters using Unicode strings.
</summary>
<param name="pServer">P4BridgeServer Handle</param>
<param name="newPort">New port </param>
<param name="newUser">New workspace</param>
<param name="newPassword">New password</param>
<param name="newClient">New workspace</param>
</member>
<member name="M:Perforce.P4.P4Bridge.set_connectionA(System.IntPtr,System.String,System.String,System.String,System.String)">
<summary>
Set the connection parameters using ASCII strings.
</summary>
<param name="pServer">P4BridgeServer Handle</param>
<param name="newPort">New port </param>
<param name="newUser">New workspace</param>
<param name="newPassword">New password</param>
<param name="newClient">New workspace</param>
</member>
<member name="M:Perforce.P4.P4Bridge.set_clientW(System.IntPtr,System.IntPtr)">
<summary>
Set the client workspace using a Unicode string
</summary>
<remarks>
The encoding should match that set by SetCharacterSet()
</remarks>
<param name="pServer">P4BridgeServer Handle</param>
<param name="workspace">Client Workspace name</param>
</member>
<member name="M:Perforce.P4.P4Bridge.set_clientA(System.IntPtr,System.String)">
<summary>
Set the client workspace using a ASCII string
</summary>
<param name="pServer">P4BridgeServer Handle</param>
<param name="workspace">Client Workspace name</param>
</member>
<member name="M:Perforce.P4.P4Bridge.get_client(System.IntPtr)">
<summary>
Get the name of the client workspace
</summary>
<remarks>
The encoding should match that set by SetCharacterSet()
</remarks>
<param name="pServer">P4BridgeServer Handle</param>
<returns>Client workspace name</returns>
</member>
<member name="M:Perforce.P4.P4Bridge.set_userW(System.IntPtr,System.IntPtr)">
<summary>
Set the user name using a Unicode string
</summary>
<remarks>
The encoding should match that set by SetCharacterSet()
</remarks>
<param name="pServer">P4BridgeServer Handle</param>
<param name="workspace">User name</param>
</member>
<member name="M:Perforce.P4.P4Bridge.set_userA(System.IntPtr,System.String)">
<summary>
Set the user name using a ASCII string
</summary>
<param name="pServer">P4BridgeServer Handle</param>
<param name="workspace">User name</param>
</member>
<member name="M:Perforce.P4.P4Bridge.get_user(System.IntPtr)">
<summary>
Get the name of the current user
</summary>
<remarks>
The encoding should match that set by SetCharacterSet()
</remarks>
<param name="pServer">P4BridgeServer Handle</param>
<returns>The user's name</returns>
</member>
<member name="M:Perforce.P4.P4Bridge.set_portW(System.IntPtr,System.IntPtr)">
<summary>
Set the connection string using a Unicode string
</summary>
<remarks>
The encoding should match that set by SetCharacterSet()
</remarks>
<param name="pServer">P4BridgeServer Handle</param>
<param name="workspace">Connection String</param>
</member>
<member name="M:Perforce.P4.P4Bridge.set_portA(System.IntPtr,System.String)">
<summary>
Set the connection string using a ASCII string
</summary>
<param name="pServer">P4BridgeServer Handle</param>
<param name="workspace">Connection String</param>
</member>
<member name="M:Perforce.P4.P4Bridge.get_port(System.IntPtr)">
<summary>
Get the connection string.
</summary>
<remarks>
The encoding should match that set by SetCharacterSet()
</remarks>
<param name="pServer">P4BridgeServer Handle</param>
<returns>host:port used by the connection</returns>
</member>
<member name="M:Perforce.P4.P4Bridge.set_passwordW(System.IntPtr,System.IntPtr)">
<summary>
Set the user's password using a Unicode string
</summary>
<remarks>
The encoding should match that set by SetCharacterSet()
</remarks>
<param name="pServer">P4BridgeServer Handle</param>
<param name="workspace">User's password</param>
</member>
<member name="M:Perforce.P4.P4Bridge.set_passwordA(System.IntPtr,System.String)">
<summary>
Set the user's password using an ASCII string
</summary>
<param name="pServer">P4BridgeServer Handle</param>
<param name="workspace">User's password</param>
</member>
<member name="M:Perforce.P4.P4Bridge.get_password(System.IntPtr)">
<summary>
Get the password used for the connection
</summary>
<remarks>
The encoding should match that set by SetCharacterSet()
</remarks>
<param name="pServer">P4BridgeServer Handle</param>
<returns>The password</returns>
</member>
<member name="M:Perforce.P4.P4Bridge.get_cwd(System.IntPtr)">
<summary>
Gets the current working directory for the P4BridgeServer.
</summary>
<param name="pServer">P4BridgeServer Handle</param>
<returns>The current working directory for the P4BridgeServer.</returns>
</member>
<member name="M:Perforce.P4.P4Bridge.set_cwdW(System.IntPtr,System.IntPtr)">
<summary>
Sets the current working directory for the P4BridgeServer using a Unicode string.
</summary>
<remarks>
The encoding should match that set by SetCharacterSet()
</remarks>
<param name="pServer">P4BridgeServer Handle</param>
<param name="cwd">The new working directory</param>
</member>
<member name="M:Perforce.P4.P4Bridge.set_cwdA(System.IntPtr,System.String)">
<summary>
Sets the current working directory for the P4BridgeServer using an ASCII string.
</summary>
<remarks>
The encoding should match that set by SetCharacterSet()
</remarks>
<param name="pServer">P4BridgeServer Handle</param>
<param name="cwd">The new working directory</param>
</member>
<member name="M:Perforce.P4.P4Bridge.set_programNameW(System.IntPtr,System.IntPtr)">
<summary>
Set the program name using a Unicode string
</summary>
<remarks>
The encoding should match that set by SetCharacterSet()
</remarks>
<param name="pServer">P4BridgeServer Handle</param>
<param name="workspace">program name</param>
</member>
<member name="M:Perforce.P4.P4Bridge.set_programNameA(System.IntPtr,System.String)">
<summary>
Set the program name using an ASCII string
</summary>
<param name="pServer">P4BridgeServer Handle</param>
<param name="workspace">program name</param>
</member>
<member name="M:Perforce.P4.P4Bridge.get_programName(System.IntPtr)">
<summary>
Get the program name used for the connection
</summary>
<remarks>
The encoding should match that set by SetCharacterSet()
</remarks>
<param name="pServer">P4BridgeServer Handle</param>
<returns>program name</returns>
</member>
<member name="M:Perforce.P4.P4Bridge.set_programVerW(System.IntPtr,System.IntPtr)">
<summary>
Set the program version using a Unicode string
</summary>
<remarks>
The encoding should match that set by SetCharacterSet()
</remarks>
<param name="pServer">P4BridgeServer Handle</param>
<param name="workspace">program version</param>
</member>
<member name="M:Perforce.P4.P4Bridge.set_programVerA(System.IntPtr,System.String)">
<summary>
Set the program version using an ASCII string
</summary>
<param name="pServer">P4BridgeServer Handle</param>
<param name="workspace">program version</param>
</member>
<member name="M:Perforce.P4.P4Bridge.get_programVer(System.IntPtr)">
<summary>
Get the program version used for the connection
</summary>
<remarks>
The encoding should match that set by SetCharacterSet()
</remarks>
<param name="pServer">P4BridgeServer Handle</param>
<returns>program version</returns>
</member>
<member name="M:Perforce.P4.P4Bridge.get_charset(System.IntPtr)">
<summary>
Get the character set used for the connection.
</summary>
<param name="pServer">Pointer to the P4BridgeServer </param>
<returns>The ANSI string representing the characterset name</returns>
</member>
<member name="M:Perforce.P4.P4Bridge.get_config(System.IntPtr)">
<summary>
Get the config file for the current connection, if any.
</summary>
<param name="pServer">Pointer to the P4BridgeServer </param>
<returns>The config file</returns>
</member>
<member name="M:Perforce.P4.P4Bridge.get_configA(System.String)">
<summary>
Get the config file for the specified directory, if any.
</summary>
<param name="pServer">Pointer to the P4BridgeServer </param>
<returns>The config file</returns>
</member>
<member name="M:Perforce.P4.P4Bridge.GetNextItem(System.IntPtr)">
<summary>
Get the Next item (a StrDict based object)
</summary>
<param name="pObj">StrDictListIterator Handle</param>
<returns>StrDictList Handle, null if end of list</returns>
</member>
<member name="M:Perforce.P4.P4Bridge.GetNextEntry(System.IntPtr)">
<summary>
Get the next dictionary entry for the current item.
</summary>
<param name="pObj">StrDictListIterator Handle</param>
<returns>Handle to a Key:Value pair</returns>
</member>
<member name="M:Perforce.P4.P4Bridge.Release(System.IntPtr)">
<summary>
Delete an object allocated on the bridge's heap when it is no
longer needed
</summary>
<param name="pObj">StrDictListIterator Handle</param>
</member>
<member name="M:Perforce.P4.P4Bridge.ReleaseArray(System.IntPtr)">
<summary>
Delete an array allocated on the bridge's heap when it is no
longer needed
</summary>
<param name="pObj">StrDictListIterator Handle</param>
</member>
<member name="M:Perforce.P4.P4Bridge.GetKey(System.IntPtr)">
<summary>
Retrieve the key
</summary>
<param name="pObj">KeyValuePair Handle</param>
<returns>Key string</returns>
</member>
<member name="M:Perforce.P4.P4Bridge.GetValue(System.IntPtr)">
<summary>
Retrieve the value
</summary>
<param name="pObj">KeyValuePair Handle</param>
<returns>String value</returns>
</member>
<member name="M:Perforce.P4.P4Bridge.Severity(System.IntPtr)">
<summary>
Severity of the error
</summary>
<param name="pObj">P4ErrorList Handle</param>
<returns>Severity level</returns>
</member>
<member name="M:Perforce.P4.P4Bridge.ErrorCode(System.IntPtr)">
<summary>
Generic code of the error
</summary>
<param name="pObj">P4ErrorList Handle</param>
<returns>Generic error code</returns>
</member>
<member name="M:Perforce.P4.P4Bridge.Message(System.IntPtr)">
<summary>
Get the error's message.
</summary>
<param name="pObj">P4ErrorList Handle</param>
<returns>Error Message</returns>
</member>
<member name="M:Perforce.P4.P4Bridge.Next(System.IntPtr)">
<summary>
Get the next error in the list
</summary>
<param name="pObj">P4ErrorList Handle</param>
<returns>null indicates the end of the list</returns>
</member>
<member name="M:Perforce.P4.P4Bridge.MessageLevel(System.IntPtr)">
<summary>
Severity of the error
</summary>
<param name="pObj">P4ClientInfoMessage Handle</param>
<returns>Severity level</returns>
</member>
<member name="M:Perforce.P4.P4Bridge.InfoMsgCode(System.IntPtr)">
<summary>
Code of the message
</summary>
<param name="pObj">P4ClientInfoMessage Handle</param>
<returns>Generic error code</returns>
</member>
<member name="M:Perforce.P4.P4Bridge.InfoMessage(System.IntPtr)">
<summary>
Get the message text.
</summary>
<param name="pObj">P4ClientInfoMessage Handle</param>
<returns>Error Message</returns>
</member>
<member name="M:Perforce.P4.P4Bridge.NextInfoMsg(System.IntPtr)">
<summary>
Get the next message in the list
</summary>
<param name="pObj">P4ClientInfoMessage Handle</param>
<returns>null indicates the end of the list</returns>
</member>
<member name="T:Perforce.P4.P4ClientMergeBridge">
<summary>
Class containing the DLL imports for the P4Bridge DLL.
</summary>
</member>
<member name="T:Perforce.P4.P4ClientResolveBridge">
<summary>
Class containing the DLL imports for the P4Bridge DLL.
</summary>
</member>
<member name="T:Perforce.P4.P4Command">
<summary>
Class wrapping command execution.
</summary>
</member>
<member name="F:Perforce.P4.P4Command.cmd">
<summary>
Command opcode
</summary>
</member>
<member name="F:Perforce.P4.P4Command.args">
<summary>
The arguments used by the command
</summary>
</member>
<member name="F:Perforce.P4.P4Command.tagged">
<summary>
Tagged protocol flag
</summary>
</member>
<member name="F:Perforce.P4.P4Command.infoResultsCallbackFn">
<summary>
Capture info results so they can be reformatted
</summary>
</member>
<member name="M:Perforce.P4.P4Command.#ctor(Perforce.P4.P4Server)">
<summary>
Create a new command
</summary>
</member>
<member name="M:Perforce.P4.P4Command.#ctor(Perforce.P4.P4Server,Perforce.P4.P4Server.PromptHandlerDelegate)">
<summary>
Create a new command
</summary>
</member>
<member name="M:Perforce.P4.P4Command.#ctor(Perforce.P4.Connection,System.String,System.Boolean,System.String[])">
<summary>
Constructer
</summary>
<param name="connection">Connection to the target Repository</param>
<param name="command">Command String i.e 'submit'</param>
<param name="taggedOutput">Run in tagged protocol</param>
<param name="arguments">Arguments for the command</param>
</member>
<member name="M:Perforce.P4.P4Command.#ctor(Perforce.P4.Repository,System.String,System.Boolean,System.String[])">
<summary>
Constructer
</summary>
<param name="repository">Target Repository</param>
<param name="command">Command String i.e 'submit'</param>
<param name="taggedOutput">Run in tagged protocol</param>
<param name="arguments">Arguments for the command</param>
</member>
<member name="M:Perforce.P4.P4Command.#ctor(Perforce.P4.Repository,System.String,Perforce.P4.P4Server.PromptHandlerDelegate,System.Boolean,System.String[])">
<summary>
Constructer
</summary>
<param name="repository">Target Repository</param>
<param name="command">Command String i.e 'submit'</param>
<param name="taggedOutput">Run in tagged protocol</param>
<param name="arguments">Arguments for the command</param>
</member>
<member name="M:Perforce.P4.P4Command.#ctor(Perforce.P4.P4Server,System.String,System.Boolean,System.String[])">
<summary>
Constructer
</summary>
<param name="server">Target P4Server</param>
<param name="command">Command String i.e 'submit'</param>
<param name="taggedOutput">Run in tagged protocol</param>
<param name="arguments">Arguments for the command</param>
</member>
<member name="M:Perforce.P4.P4Command.#ctor(Perforce.P4.P4Server,System.String,Perforce.P4.P4Server.PromptHandlerDelegate,System.Boolean,System.String[])">
<summary>
Constructer
</summary>
<param name="server">Target P4Server</param>
<param name="command">Command String i.e 'submit'</param>
<param name="taggedOutput">Run in tagged protocol</param>
<param name="arguments">Arguments for the command</param>
</member>
<member name="M:Perforce.P4.P4Command.OnInfoOut(System.UInt32,System.Int32,System.Int32,System.String)">
<summary>
Use the infoResultsReceived event to build up a list of info data.
</summary>
<param name="level">level of the message</param>
<param name="info">message text</param>
</member>
<member name="M:Perforce.P4.P4Command.HandlePrompt(System.UInt32,System.String,System.Boolean)">
<summary>
Respond to a prompt from the server for input
</summary>
<param name="msg"></param>
<param name="displayText"></param>
<returns></returns>
</member>
<member name="M:Perforce.P4.P4Command.Run(Perforce.P4.StringList)">
<summary>
Run the command supplying additional arguments
</summary>
<param name="flags">Additional arguments inserted in front of the current arguments</param>
<returns>Success/Failure</returns>
</member>
<member name="M:Perforce.P4.P4Command.Run">
<summary>
Run the command using the existing arguments
</summary>
<returns></returns>
</member>
<member name="M:Perforce.P4.P4Command.RunInt(Perforce.P4.StringList)">
<summary>
Run the command supplying additional arguments
</summary>
<param name="flags">Additional arguments inserted in front of the current arguments</param>
<returns></returns>
</member>
<member name="M:Perforce.P4.P4Command.Dispose">
<summary>
Dispose of any resources
</summary>
</member>
<member name="P:Perforce.P4.P4Command.CommandId">
<summary>
Unique Id set each time command is run
</summary>
</member>
<member name="P:Perforce.P4.P4Command.InfoOutput">
<summary>
Get the info results from the command execution
</summary>
</member>
<member name="P:Perforce.P4.P4Command.ErrorOutput">
<summary>
Get the error results from the command execution
</summary>
</member>
<member name="P:Perforce.P4.P4Command.TextOutput">
<summary>
Get the text output from the command execution
</summary>
</member>
<member name="P:Perforce.P4.P4Command.TaggedOutput">
<summary>
Get the tagged results from the command execution
</summary>
</member>
<member name="P:Perforce.P4.P4Command.BinaryOutput">
<summary>
Get the binary from the command execution
</summary>
</member>
<member name="P:Perforce.P4.P4Command.Cmd">
<summary>
Command String i.e 'submit'
</summary>
</member>
<member name="P:Perforce.P4.P4Command.Args">
<summary>
Arguments for the command
</summary>
</member>
<member name="P:Perforce.P4.P4Command.Tagged">
<summary>
Run in tagged protocol
</summary>
</member>
<member name="P:Perforce.P4.P4Command.Responses">
<summary>
Dictionary of responses to prompts from the server, where the key
is the expected prompt from the server and the value is the
desired response.
</summary>
</member>
<member name="P:Perforce.P4.P4Command.DataSet">
<summary>
Data to be processed by the command
</summary>
</member>
<member name="T:Perforce.P4.P4Exception">
<summary>
Base class for exceptions caused by run time errors from the server.
They can be disabled, by setting the MinThrowLevel to
ErrorSeverity.E_NOEXC.
</summary>
</member>
<member name="M:Perforce.P4.P4Exception.#ctor(Perforce.P4.ErrorSeverity,System.String)">
<summary>
Create a new P4Exception
</summary>
<param name="nLevel">Severity level</param>
<param name="nMessage">Error message</param>
</member>
<member name="M:Perforce.P4.P4Exception.#ctor(Perforce.P4.ErrorSeverity,System.String,Perforce.P4.P4Exception)">
<summary>
Create a new P4Exception
</summary>
<param name="nLevel">Severity level</param>
<param name="nMessage">Error message</param>
<param name="NextError">Next error in sequence</param>
</member>
<member name="M:Perforce.P4.P4Exception.#ctor(System.String,System.String[],Perforce.P4.ErrorSeverity,System.String)">
<summary>
Create a new P4Exception
</summary>
<param name="nLevel">Severity level</param>
<param name="nMessage">Error message</param>
<param name="NextError">Next error in sequence</param>
</member>
<member name="M:Perforce.P4.P4Exception.#ctor(Perforce.P4.P4ClientError)">
<summary>
Create a new P4Exception
</summary>
<param name="error">Client error causing the exception</param>
</member>
<member name="M:Perforce.P4.P4Exception.#ctor(System.String,System.String[],Perforce.P4.P4ClientError)">
<summary>
Create a new P4Exception
</summary>
<param name="error">Client error causing the exception</param>
</member>
<member name="M:Perforce.P4.P4Exception.#ctor(Perforce.P4.P4ClientErrorList)">
<summary>
Create a list of new P4Exceptions
</summary>
<param name="errors">The list of errors which caused the exception</param>
</member>
<member name="M:Perforce.P4.P4Exception.#ctor(System.String,System.String[],Perforce.P4.P4ClientErrorList)">
<summary>
Create a list of new P4Exceptions
</summary>
<param name="errors">The list of errors which caused the exception</param>
</member>
<member name="M:Perforce.P4.P4Exception.#ctor(Perforce.P4.P4ClientErrorList,Perforce.P4.P4ClientInfoMessageList)">
<summary>
Create a list of new P4Exceptions
</summary>
<param name="errors">The list of errors which caused the exception</param>
<param name="nDetails">The info output of the command which caused the exception</param>
</member>
<member name="M:Perforce.P4.P4Exception.#ctor(System.String,System.String[],Perforce.P4.P4ClientErrorList,Perforce.P4.P4ClientInfoMessageList)">
<summary>
Create a list of new P4Exceptions
</summary>
<param name="errors">The list of errors which caused the exception</param>
<param name="nDetails">The info output of the command which caused the exception</param>
</member>
<member name="M:Perforce.P4.P4Exception.Throw(Perforce.P4.ErrorSeverity,System.String)">
<summary>
Create and throw an exception if it exceeds the MinThrowLevel
</summary>
<param name="nLevel">Severity level</param>
<param name="nMessage">Error message</param>
</member>
<member name="M:Perforce.P4.P4Exception.Throw(System.String,System.String[],Perforce.P4.ErrorSeverity,System.String)">
<summary>
Create and throw an exception if it exceeds the MinThrowLevel
</summary>
<param name="nLevel">Severity level</param>
<param name="nMessage">Error message</param>
</member>
<member name="M:Perforce.P4.P4Exception.Throw(Perforce.P4.P4ClientError)">
<summary>
Create and throw an exception if it exceeds the MinThrowLevel
</summary>
<param name="error">Client error causing the exception</param>
</member>
<member name="M:Perforce.P4.P4Exception.Throw(System.String,System.String[],Perforce.P4.P4ClientError)">
<summary>
Create and throw an exception if it exceeds the MinThrowLevel
</summary>
<param name="error">Client error causing the exception</param>
</member>
<member name="M:Perforce.P4.P4Exception.Throw(Perforce.P4.P4ClientErrorList)">
<summary>
Throw if any error in the list exceeds minLevel
</summary>
<param name="errors">List of client errors causing the exception</param>
</member>
<member name="M:Perforce.P4.P4Exception.Throw(System.String,System.String[],Perforce.P4.P4ClientErrorList)">
<summary>
Throw if any error in the list exceeds minLevel
</summary>
<param name="errors">List of client errors causing the exception</param>
</member>
<member name="M:Perforce.P4.P4Exception.Throw(Perforce.P4.P4ClientErrorList,Perforce.P4.P4ClientInfoMessageList)">
<summary>
Throw if any error in the list exceeds minLevel
</summary>
<param name="errors">List of client errors causing the exception</param>
</member>
<member name="M:Perforce.P4.P4Exception.Throw(System.String,System.String[],Perforce.P4.P4ClientErrorList,Perforce.P4.P4ClientInfoMessageList)">
<summary>
Throw if any error in the list exceeds minLevel
</summary>
<param name="errors">List of client errors causing the exception</param>
</member>
<member name="P:Perforce.P4.P4Exception.NextError">
<summary>
If more than one error was returned by a command, the next
error in the list.
</summary>
</member>
<member name="P:Perforce.P4.P4Exception.ErrorLevel">
<summary>
Severity of the error
</summary>
</member>
<member name="P:Perforce.P4.P4Exception.ErrorCode">
<summary>
Error number from the C++ API
</summary>
</member>
<member name="P:Perforce.P4.P4Exception.Message">
<summary>
Error message
</summary>
</member>
<member name="P:Perforce.P4.P4Exception.Details">
<summary>
Error message
</summary>
</member>
<member name="P:Perforce.P4.P4Exception.CmdLine">
<summary>
Error message
</summary>
</member>
<member name="P:Perforce.P4.P4Exception.MinThrowLevel">
<summary>
Minimum error to cause an exception to be thrown
</summary>
</member>
<member name="T:Perforce.P4.P4MapApi">
<summary>
P4MapApi: .NET wrapper for the MapApi object in the p4api dll.
</summary>
</member>
<member name="M:Perforce.P4.P4MapApi.MarshalPtrToString(System.IntPtr)">
<summary>
Translate a returned string based on the UseUnicode setting
</summary>
<param name="pStr"> Native pointer to the string</param>
<returns>UTF-16 String</returns>
</member>
<member name="M:Perforce.P4.P4MapApi.MarshalStringToIntPtr(System.String)">
<summary>
Marshal a String into UTF8 to pass when
UseUnicode is set.
</summary>
<param name="arg">String to encode</param>
<returns>IntPtr of the encoded string</returns>
</member>
<member name="M:Perforce.P4.P4MapApi.#ctor(Perforce.P4.P4Server)">
<summary>
Create a new P4MapApi
</summary>
<param name="pserver">The P4Server on which the map will be used</param>
<remarks>
The server is needed to know whether or not it is necessary to translate
strings to/from Unicode </remarks>
</member>
<member name="M:Perforce.P4.P4MapApi.#ctor(System.Boolean)">
<summary>
Create a new P4MapApi
</summary>
<param name="pserver">The P4Server on which the map will be used</param>
<remarks>
The server is needed to know whether or not it is necessary to translate
strings to/from Unicode </remarks>
</member>
<member name="M:Perforce.P4.P4MapApi.#ctor(System.Boolean,System.IntPtr)">
<summary>
Wrap the pointer to MapApi object in a P4MapApi
</summary>
<param name="pserver">The P4Server on which the map will be used</param>
<param name="pNew">The MapApi pointer to wrap</param>
<remarks>
The server is needed to know whether or not it is necessary to translate
strings to/from Unicode </remarks>
</member>
<member name="M:Perforce.P4.P4MapApi.Finalize">
<summary>
Delete the P4MapApi object and free the native object from the dll.
</summary>
</member>
<member name="M:Perforce.P4.P4MapApi.CreateMapApi">
<summary>
Helper function to create a new MapApi object.
</summary>
<returns>IntPtr to the new object</returns>
<remarks>Call DeletMapApi() on the returned pointer to free the object</remarks>
</member>
<member name="M:Perforce.P4.P4MapApi.DeleteMapApi(System.IntPtr)">
<summary>
Helper function to delete a MapApi object allocated by CreateMApApi().
</summary>
<param name="pMap">IntPtr for the object to be deleted</param>
</member>
<member name="M:Perforce.P4.P4MapApi.Clear">
<summary>
Clear all the data in the map
</summary>
</member>
<member name="M:Perforce.P4.P4MapApi.GetLeft(System.Int32)">
<summary>
Return the left side of the specified entry in the map
</summary>
<param name="idx">Index of the desired entry</param>
<returns>String representing the left side of the entry</returns>
</member>
<member name="M:Perforce.P4.P4MapApi.GetRight(System.Int32)">
<summary>
Return the right side of the specified entry in the map
</summary>
<param name="idx">Index of the desired entry</param>
<returns>String representing the right side of the entry</returns>
</member>
<member name="M:Perforce.P4.P4MapApi.GetType(System.Int32)">
<summary>
Return the type of the specified entry in the map
</summary>
<param name="idx">Index of the desired entry</param>
<returns>The P4MapApi.Type enumeration for the type of the entry</returns>
</member>
<member name="M:Perforce.P4.P4MapApi.Insert(System.String,Perforce.P4.P4MapApi.Type)">
<summary>
Adds a new entry in the map
</summary>
<param name="lr">String representing both the the left and right sides of
the new entry</param>
<param name="t">Type of the new entry</param>
</member>
<member name="M:Perforce.P4.P4MapApi.Insert(System.String,System.String,Perforce.P4.P4MapApi.Type)">
<summary>
Adds a new entry in the map
</summary>
<param name="left">String representing the the left side of the new entry</param>
<param name="right">String representing the the right side of the new entry</param>
<param name="type">Type of the new entry</param>
</member>
<member name="M:Perforce.P4.P4MapApi.Join(Perforce.P4.P4MapApi,Perforce.P4.P4MapApi)">
<summary>
Combine two MapApis to create a new MapApi
</summary>
<param name="left">Pointer to the first map</param>
<param name="right">Pointer to the second map</param>
<returns></returns>
</member>
<member name="M:Perforce.P4.P4MapApi.Join(Perforce.P4.P4MapApi,Perforce.P4.P4MapApi.Direction,Perforce.P4.P4MapApi,Perforce.P4.P4MapApi.Direction)">
<summary>
Combine two MapApis to create a new MapApi
</summary>
<param name="left">Pointer to the first map</param>
<param name="leftDir">Orientation of the first map</param>
<param name="right">Pointer to the second map</param>
<param name="rightDir">Orientation of the second map</param>
<returns></returns>
</member>
<member name="M:Perforce.P4.P4MapApi.Translate(System.String,Perforce.P4.P4MapApi.Direction)">
<summary>
Translate a file path from on side of the mapping to the other
</summary>
<param name="path">The path to translate</param>
<param name="direction">The direction to perform the translation L->R or R->L</param>
<returns>Translated path, Null if no translation (path is not mapped)</returns>
</member>
<member name="M:Perforce.P4.P4MapApi.Dispose">
<summary>
Free the wrapped native object
</summary>
</member>
<member name="P:Perforce.P4.P4MapApi.Count">
<summary>
The number of entries in the map
</summary>
</member>
<member name="T:Perforce.P4.P4MapApi.Type">
<summary>
Type of the map entry, Include, Exclude, Overlay.
</summary>
</member>
<member name="F:Perforce.P4.P4MapApi.Type.Include">
<summary>
Include the indicated mapping
</summary>
</member>
<member name="F:Perforce.P4.P4MapApi.Type.Exclude">
<summary>
Exclude the indicated mapping
</summary>
</member>
<member name="F:Perforce.P4.P4MapApi.Type.Overlay">
<summary>
Overlay the indicated mapping
</summary>
</member>
<member name="T:Perforce.P4.P4MapApi.Direction">
<summary>
Specify the direction to perform the mapping.
</summary>
</member>
<member name="F:Perforce.P4.P4MapApi.Direction.LeftRight">
<summary>
Map from left to right
</summary>
</member>
<member name="F:Perforce.P4.P4MapApi.Direction.RightLeft">
<summary>
Map from right to left
</summary>
</member>
<member name="T:Perforce.P4.Fix">
<summary>
Specifies a fix relationship between one or more jobs and one
or more changelists.
</summary>
</member>
<member name="T:Perforce.P4.FixAction">
<summary>
The fix action (Fixed or Unfixed).
</summary>
</member>
<member name="F:Perforce.P4.FixAction.Fixed">
<summary>
Fixed
</summary>
</member>
<member name="F:Perforce.P4.FixAction.Unfixed">
<summary>
Fix removed
</summary>
</member>
<member name="T:Perforce.P4.FormBase">
<summary>
Describes fields and comments in a Perforce specification.
</summary>
</member>
<member name="M:Perforce.P4.FormBase.SetValues(Perforce.P4.TaggedObject)">
<summary>
Set the Values Dictionary from tagged output of a Perforce command.
</summary>
<remarks>
Needed when the object's data dictionary is set after the object
is created using the default constructer.
</remarks>
<param name="data">Object data</param>
</member>
<member name="M:Perforce.P4.FormBase.Parse(System.String)">
<summary>
Parse a string specification in the server format into an object.
</summary>
<remarks>
The base implementation parses the generic specification tag::value
format into the underlying dictionary
</remarks>
<param name="spec">String specification</param>
<returns>Success/Failure</returns>
</member>
<member name="M:Perforce.P4.FormBase.ToString">
<summary>
Create a form specification from the fields that make up a form
</summary>
<returns></returns>
</member>
<member name="M:Perforce.P4.FormBase.FormatDateTime(System.DateTime)">
<summary>
Utility function to format a DateTime in the format expected in a spec
</summary>
<param name="dt"></param>
<returns></returns>
</member>
<member name="M:Perforce.P4.FormBase.ConvertUnixTime(System.Int64)">
<summary>
Utility to convert a Unix time (Seconds past midnight 1/1/1970) to a DateTime
</summary>
<param name="unixTime"></param>
<returns></returns>
</member>
<member name="M:Perforce.P4.FormBase.ConvertUnixTime(System.String)">
<summary>
Utility to convert a Unix time (Seconds past midnight 1/1/1970) to a DateTime
</summary>
<param name="unixTimeStr">Unix time as a string</param>
<returns></returns>
</member>
<member name="M:Perforce.P4.FormBase.FormatMultilineField(System.String)">
<summary>
Utility to properly format multi-line fields in forms
</summary>
<param name="multiLine">Multi-line field</param>
<returns></returns>
</member>
<member name="T:Perforce.P4.SpecFieldDataType">
<summary>
Field Data Type for a field in a form specification.
</summary>
</member>
<member name="F:Perforce.P4.SpecFieldDataType.None">
<summary>
No value.
</summary>
</member>
<member name="F:Perforce.P4.SpecFieldDataType.Word">
<summary>
Word: a single word (any value).
</summary>
</member>
<member name="F:Perforce.P4.SpecFieldDataType.Date">
<summary>
Date: a date/time field.
</summary>
</member>
<member name="F:Perforce.P4.SpecFieldDataType.Select">
<summary>
Select: one of a set of words.
</summary>
</member>
<member name="F:Perforce.P4.SpecFieldDataType.Line">
<summary>
Line: a one-liner.
</summary>
</member>
<member name="F:Perforce.P4.SpecFieldDataType.Text">
<summary>
Text: a block of text.
</summary>
</member>
<member name="F:Perforce.P4.SpecFieldDataType.Bulk">
<summary>
Bulk: text not indexed for 'p4 jobs -e'
</summary>
</member>
<member name="T:Perforce.P4.SpecFieldFieldType">
<summary>
Field Type for a field in a form specification.
</summary>
</member>
<member name="F:Perforce.P4.SpecFieldFieldType.Key">
<summary>
The unique identifier for the field.
</summary>
</member>
<member name="F:Perforce.P4.SpecFieldFieldType.Required">
<summary>
Required: default provided, value must be present.
</summary>
</member>
<member name="F:Perforce.P4.SpecFieldFieldType.Always">
<summary>
Always: always set to the default when saving the form.
</summary>
</member>
<member name="F:Perforce.P4.SpecFieldFieldType.Optional">
<summary>
Optional: no default, and not required to be present.
</summary>
</member>
<member name="F:Perforce.P4.SpecFieldFieldType.Default">
<summary>
Default: default provided, still not required.
</summary>
</member>
<member name="F:Perforce.P4.SpecFieldFieldType.Once">
<summary>
Once: set once to the default and never changed.
</summary>
</member>
<member name="T:Perforce.P4.FormSpec">
<summary>
Specifies structural and semantic metadata for form types.
</summary>
</member>
<member name="M:Perforce.P4.FormSpec.#ctor">
<summary>
Create an empty FormSpec
</summary>
</member>
<member name="M:Perforce.P4.FormSpec.#ctor(System.Collections.Generic.List{Perforce.P4.SpecField},System.Collections.Generic.Dictionary{System.String,System.String},System.Collections.Generic.List{System.String},System.Collections.Generic.List{System.String},System.Collections.Generic.Dictionary{System.String,System.String},System.Collections.Generic.Dictionary{System.String,System.String},System.String)">
<summary>
Create a FormSpec
</summary>
</member>
<member name="M:Perforce.P4.FormSpec.FromSpecCmdTaggedOutput(Perforce.P4.TaggedObject)">
<summary>
Create a FormSpec from the tagged output of the 'spec' command
</summary>
<param name="obj">Tagged object returned by the 'spec' command</param>
<returns></returns>
</member>
<member name="P:Perforce.P4.FormSpec.Fields">
<summary>
List of all SpecField objects for all fields defined for this Form type.
</summary>
</member>
<member name="P:Perforce.P4.FormSpec.FieldMap">
<summary>
Map, keyed by SpecField name, containing suitable allowed values for specific form fields.
</summary>
</member>
<member name="P:Perforce.P4.FormSpec.Words">
<summary>
List of "words" for this form type.
</summary>
</member>
<member name="P:Perforce.P4.FormSpec.Formats">
<summary>
List of "formats" for this form type.
</summary>
</member>
<member name="P:Perforce.P4.FormSpec.Values">
<summary>
Map, keyed by SpecField name, containing suitable allowed values for specific form fields.
</summary>
<remarks>
See the main Perforce documentation for formats used here.
</remarks>
</member>
<member name="P:Perforce.P4.FormSpec.Presets">
<summary>
Map, keyed by SpecField name, containing preset (default) values for specific form fields.
</summary>
<remarks>
See the main Perforce documentation for formats used here.
</remarks>
</member>
<member name="P:Perforce.P4.FormSpec.Comments">
<summary>
a single (possibly rather long) string (which may contain embedded
newlines) containing comments to be optionally used in GUI or
other representations of the form type.
</summary>
</member>
<member name="T:Perforce.P4.SpecField">
<summary>
Class representing a field in a FormSpec.
</summary>
</member>
<member name="M:Perforce.P4.SpecField.#ctor">
<summary>
Create a default FormSpec
</summary>
</member>
<member name="M:Perforce.P4.SpecField.#ctor(System.Int32,System.String,Perforce.P4.SpecFieldDataType,System.Int32,Perforce.P4.SpecFieldFieldType)">
<summary>
Create a FormSpec
</summary>
</member>
<member name="M:Perforce.P4.SpecField.FromSpecCmdTaggedData(System.String)">
<summary>
Create a SpecField from a 'Fields' entry in the tagged data from the 'spec' command.
</summary>
<param name="def"></param>
<returns></returns>
</member>
<member name="P:Perforce.P4.SpecField.Code">
<summary>
Numeric code identifying this form field.
</summary>
</member>
<member name="P:Perforce.P4.SpecField.Name">
<summary>
Name of this form field.
</summary>
</member>
<member name="P:Perforce.P4.SpecField.DataType">
<summary>
A field's type, i.e. whether it's a single word, a date, a selection, or a text field
</summary>
</member>
<member name="P:Perforce.P4.SpecField.Length">
<summary>
The maximum length in characters (?) of this field.
</summary>
</member>
<member name="P:Perforce.P4.SpecField.FieldType">
<summary>
Specifies whether the field is optional, required, a key, or set by the server.
</summary>
</member>
<member name="T:Perforce.P4.Job">
<summary>
A Job in the Repository.
</summary>
<remarks>
A job specification has only one required field, "Job". If
a Perforce installation uses a complex Job specification than
the simple parsing and string formatting provided by the Form
object cannot properly support the data, the Job object can
subclassed to provide custom parsing and form generation
<br/><b>p4 help job</b>
<br/>
<br/> job -- Create or edit a job (defect) specification
<br/>
<br/> p4 job [-f] [jobName]
<br/> p4 job -d jobName
<br/> p4 job -o [jobName]
<br/> p4 job -i [-f]
<br/>
<br/> The 'p4 job' command creates and edits job specifications using an
<br/> ASCII form. A job is a defect, enhancement, or other unit of
<br/> intended work.The 'p4 fix' command associates changelists with jobs.
<br/>
<br/> With no arguments, 'p4 job' creates an empty job specification
<br/> and invokes the user's editor. When the specification is saved,
<br/> a job name of the form jobNNNNNN is assigned. If the jobName
<br/> parameter is specified on the command line, the job is created or
<br/> opened for editing.
<br/>
<br/> As jobs are entered or updated, all fields are indexed for searching
<br/> Text fields are broken into individual alphanumeric words (punctuation
<br/> and whitespace are ignored) and each word is case-folded and entered
<br/> into the word index. Date fields are converted to an internal
<br/> representation (seconds since 1970/01/01 00:00:00) and entered
<br/> into the date index.
<br/>
<br/> The fields that compose a job are defined by the 'p4 jobspec' command.
<br/> Perforce provides a default job specification that you can edit.
<br/>
<br/> The -d flag deletes the specified job. You cannot delete a job if
<br/> it has pending or submitted fixes associated with it.
<br/>
<br/> The -o flag writes the job specification to the standard output.
<br/> The user's editor is not invoked.
<br/>
<br/> The -i flag reads a job specification from the standard input. The
<br/> user's editor is not invoked.
<br/>
<br/> The -f flag enables you set fields that are read-only by default.
<br/> The -f flag requires 'admin' access, which is granted using the
<br/> 'p4 protect' command.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Job.ToString">
<summary>
Convert to a Job specification
</summary>
<returns></returns>
</member>
<member name="M:Perforce.P4.Job.FromJobCmdTaggedOutput(Perforce.P4.TaggedObject)">
<summary>
Parse the tagged output of a 'job' command
</summary>
<param name="obj"></param>
</member>
<member name="M:Perforce.P4.Job.Parse(System.String)">
<summary>
Parse a Job spec
</summary>
<param name="spec"></param>
</member>
<member name="M:Perforce.P4.Job.ToStrings(System.Collections.Generic.IList{Perforce.P4.Job})">
<summary>
Convert the Job to a Spec Def
</summary>
<param name="list"></param>
<returns></returns>
</member>
<member name="M:Perforce.P4.Job.ToStrings(Perforce.P4.Job[])">
<summary>
Convert an array of Jobs to a list of JobIds to be passed as
parameters to a command
</summary>
<param name="list"></param>
<returns></returns>
</member>
<member name="P:Perforce.P4.Job.Id">
<summary>
The job name
</summary>
</member>
<member name="T:Perforce.P4.Label">
<summary>
A label specification in a Perforce repository.
</summary>
</member>
<member name="M:Perforce.P4.Label.FromLabelCmdTaggedOutput(Perforce.P4.TaggedObject)">
<summary>
Read the fields from the tagged output of a label command
</summary>
<param name="objectInfo">Tagged output from the 'label' command</param>
</member>
<member name="M:Perforce.P4.Label.Parse(System.String)">
<summary>
Parse the fields from a label specification
</summary>
<param name="spec">Text of the label specification in server format</param>
<returns></returns>
</member>
<member name="F:Perforce.P4.Label.LabelFormat">
<summary>
Format of a label specification used to save a label to the server
</summary>
</member>
<member name="M:Perforce.P4.Label.ToString">
<summary>
Convert to specification in server format
</summary>
<returns></returns>
</member>
<member name="M:Perforce.P4.Label.FromLabelsCmdTaggedOutput(Perforce.P4.TaggedObject,System.String,System.Boolean)">
<summary>
Read the fields from the tagged output of a labels command
</summary>
<param name="objectInfo">Tagged output from the 'labels' command</param>
</member>
<member name="T:Perforce.P4.Options">
<summary>
A generic list of command options and values.
</summary>
<summary>
Options for the resolve command
</summary>
<summary>
Options for the stream command
</summary>
<summary>
Options for the streams command
</summary>
<summary>
Options for the istat command
</summary>
<summary>
</summary>
<summary>
Options for the branch command
</summary>
<summary>
Options for the branches command
</summary>
<summary>
Options for the label command
</summary>
<summary>
Options for the labels command
</summary>
<summary>
Options for the labels command
</summary>
<summary>
Options for the diff2 command
</summary>
<summary>
Options for GetOpenedFiles
</summary>
<summary>
Options for the fstat command
</summary>
<summary>
Options for the files command
</summary>
<remarks>
<br/><b>p4 help files</b>
<br/>
<br/> files -- List files in the depot
<br/>
<br/> p4 files [ -a ] [ -A ] [ -e ] [ -m max ] file[revRange] ...
<br/> p4 files -U unloadfile ...
<br/>
<br/> List details about specified files: depot file name, revision,
<br/> file, type, change action and changelist number of the current
<br/> head revision. If client syntax is used to specify the file
<br/> argument, the client view mapping is used to determine the
<br/> corresponding depot files.
<br/>
<br/> By default, the head revision is listed. If the file argument
<br/> specifies a revision, then all files at that revision are listed.
<br/> If the file argument specifies a revision range, the highest revision
<br/> in the range is used for each file. For details about specifying
<br/> revisions, see 'p4 help revisions'.
<br/>
<br/> The -a flag displays all revisions within the specific range, rather
<br/> than just the highest revision in the range.
<br/>
<br/> The -A flag displays files in archive depots.
<br/>
<br/> The -e flag displays files with an action of anything other than
<br/> deleted, purged or archived. Typically this revision is always
<br/> available to sync or integrate from.
<br/>
<br/> The -m flag limits files to the first 'max' number of files.
<br/>
<br/> The -U option displays files in the unload depot (see 'p4 help unload'
<br/> for more information about the unload depot).
<br/>
<br/>
</remarks>
<summary>
Options for the dirs command
</summary>
<summary>
Options for the print command
</summary>
<summary>
Options for the filelog command
</summary>
<summary>
Options for the annotate command
</summary>
<summary>
Options for the fixes command
</summary>
<summary>
Options for the grep command
</summary>
<summary>
Options for the integrated command
</summary>
<summary>
Options for the protects command
</summary>
<summary>
Options for the reviews command
</summary>
<summary>
Options for the triggers command
</summary>
<summary>
Options for the typemap command
</summary>
<summary>
Options for the protect command
</summary>
<summary>
Options for the counter command
</summary>
</member>
<member name="M:Perforce.P4.Options.#ctor">
<summary>
Construct an blank Options object
</summary>
</member>
<member name="M:Perforce.P4.Options.#ctor(Perforce.P4.AddFilesCmdFlags,System.Int32,Perforce.P4.FileType)">
<summary>
Options for the Add command.
</summary>
<param name="flags">Flags for the command</param>
<param name="changeList">Optional changelist for the fies</param>
<param name="fileType">Optional file type for the files</param>
<returns></returns>
<remarks>
<br/><b>p4 help add</b>
<br/>
<br/> add -- Open a new file to add it to the depot
<br/>
<br/> p4 add [-c changelist#] [-d -f -I -n] [-t filetype] file ...
<br/>
<br/> Open a file for adding to the depot. If the file exists on the
<br/> client, it is read to determine if it is text or binary. If it does
<br/> not exist, it is assumed to be text. To be added, the file must not
<br/> already reside in the depot, or it must be deleted at the current
<br/> head revision. Files can be deleted and re-added.
<br/>
<br/> A 2012.1 client will ignore files that were to be added, if they
<br/> match an exclusion line specified in a P4IGNORE file.
<br/>
<br/> To associate the open files with a specific pending changelist, use
<br/> the -c flag; if you omit the -c flag, the open files are associated
<br/> with the default changelist. If file is already open, it is moved
<br/> into the specified pending changelist. You cannot reopen a file for
<br/> add unless it is already open for add.
<br/>
<br/> As a shortcut to reverting and re-adding, you can use the -d
<br/> flag to reopen currently-open files for add (downgrade) under
<br/> the following circumstances:
<br/>
<br/> A file that is 'opened for edit' and is synced to the head
<br/> revision, and the head revision has been deleted (or moved).
<br/>
<br/> A file that is 'opened for move/add' can be downgraded to add,
<br/> which is useful when the source of the move has been deleted
<br/> or moved. Typically, under these circumstances, your only
<br/> alternative is to revert. In this case, breaking the move
<br/> connection enables you to preserve any content changes in the
<br/> new file and safely revert the source file (of the move).
<br/>
<br/> To specify file type, use the -t flag. By default, 'p4 add'
<br/> determines file type using the name-to-type mapping table managed
<br/> by 'p4 typemap' and by examining the file's contents and execute
<br/> permission bit. If the file type specified by -t or configured in
<br/> the typemap table is a partial filetype, the resulting modifier is
<br/> applied to the file type that is determined by 'p4 add'. For more
<br/> details, see 'p4 help filetypes'.
<br/>
<br/> To add files with filenames that contain wildcard characters, specify
<br/> the -f flag. Filenames that contain the special characters '@', '#',
<br/> '%' or '*' are reformatted to encode the characters using ASCII
<br/> hexadecimal representation. After the files are added, you must
<br/> refer to them using the reformatted file name, because Perforce
<br/> does not recognize the local filesystem name.
<br/>
<br/> The -I flag informs the client that it should not perform any ignore
<br/> checking configured by P4IGNORE.
<br/>
<br/> The -n flag displays a preview of the specified add operation without
<br/> changing any files or metadata.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Options.#ctor(Perforce.P4.DeleteFilesCmdFlags,System.Int32)">
<summary>
Options for the delete command.
</summary>
<param name="flags"></param>
<param name="changeList"></param>
<returns></returns>
<remarks>
<br/><b>p4 help delete</b>
<br/>
<br/> delete -- Open an existing file for deletion from the depot
<br/>
<br/> p4 delete [-c changelist#] [-n -v -k] file ...
<br/>
<br/> Opens a depot file for deletion.
<br/> If the file is synced in the client workspace, it is removed. If a
<br/> pending changelist number is specified using with the -c flag, the
<br/> file is opened for delete in that changelist. Otherwise, it is opened
<br/> in the default pending changelist.
<br/>
<br/> Files that are deleted generally do not appear on the have list.
<br/>
<br/> The -n flag displays a preview of the operation without changing any
<br/> files or metadata.
<br/>
<br/> The -k flag performs the delete on the server without modifying
<br/> client files. Use with caution, as an incorrect delete can cause
<br/> discrepancies between the state of the client and the corresponding
<br/> server metadata.
<br/>
<br/> The -v flag enables you to delete files that are not synced to the
<br/> client workspace. The files should be specified using depot syntax;
<br/> since the files are not synced, client syntax or local syntax are
<br/> inappropriate and could introduce ambiguities in the file list.
<br/> Note, though, that if the files ARE synced, 'delete -v' will remove
<br/> the files from the client in addition to opening them for delete.
<br/> The preferred way to delete a set of files without transferring
<br/> them to your machine is: 'sync -k file...', then 'delete -k file...'
<br/>
<br/> 'p4 delete' is not supported for files with propagating attributes
<br/> from an edge server in a distributed environment.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Options.#ctor(Perforce.P4.EditFilesCmdFlags,System.Int32,Perforce.P4.FileType)">
<summary>
Options for the edit command
</summary>
<param name="flags"></param>
<param name="changeList"></param>
<param name="fileType"></param>
<returns></returns>
<remarks>
<br/><b>p4 help edit</b>
<br/>
<br/> edit -- Open an existing file for edit
<br/>
<br/> p4 edit [-c changelist#] [-k -n] [-t filetype] file ...
<br/>
<br/> Open an existing file for edit. The server records the fact that
<br/> the current user has opened the file in the current workspace, and
<br/> changes the file permission from read-only to read/write.
<br/>
<br/> If -c changelist# is included, the file opened in the specified
<br/> pending changelist. If changelist number is omitted, the file is
<br/> opened in the 'default' changelist.
<br/>
<br/> If -t filetype is specified, the file is assigned that Perforce
<br/> filetype. Otherwise, the filetype of the previous revision is reused.
<br/> If a partial filetype is specified, it is combined with the current
<br/> filetype.For details, see 'p4 help filetypes'.
<br/> Using a filetype of 'auto' will cause the filetype to be chosen
<br/> as if the file were being added, that is the typemap will be
<br/> considered and the file contents may be examined.
<br/>
<br/> The -n flag previews the operation without changing any files or
<br/> metadata.
<br/>
<br/> The -k flag updates metadata without transferring files to the
<br/> workspace. This option can be used to tell the server that files in
<br/> a client workspace are already editable, even if they are not in the
<br/> client view. Typically this flag is used to correct the Perforce
<br/> server when it is wrong about the state of files in the client
<br/> workspace, but incorrect use of this option can result in inaccurate
<br/> file status information.
<br/>
<br/> 'p4 edit' is not supported for files with propagating attributes
<br/> from an edge server in a distributed environment.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Options.#ctor(Perforce.P4.IntegrateFilesCmdFlags,System.Int32,System.Int32,System.String,System.String,System.String)">
<summary>
Options for the integrate command.
</summary>
<param name="fromFile"></param>
<returns></returns>
<remarks>
<br/><b>p4 help integrate</b>
<br/>
<br/> integrate -- Integrate one set of files into another
<br/>
<br/> p4 integrate [options] fromFile[revRange] toFile
<br/> p4 integrate [options] -b branch [-r] [toFile[revRange] ...]
<br/> p4 integrate [options] -b branch -s fromFile[revRange] [toFile ...]
<br/> p4 integrate [options] -S stream [-r] [-P parent] [file[revRange] ...]
<br/>
<br/> options: -c changelist# -Di -f -h -O<flags> -n -m max -R<flags> -q -v
<br/>
<br/> 'p4 integrate' integrates one set of files (the 'source') into
<br/> another (the 'target').
<br/>
<br/> (See also 'p4 merge' and 'p4 copy', variants of 'p4 integrate' that
<br/> may be easier and more effective for the task at hand.)
<br/>
<br/> Using the client workspace as a staging area, 'p4 integrate' adds and
<br/> deletes target files per changes in the source, and schedules all
<br/> other affected target files to be resolved. Target files outside of
<br/> the current client view are not affected. Source files need not be
<br/> within the client view.
<br/>
<br/> 'p4 resolve' must be used to merge file content, and to resolve
<br/> filename and filetype changes. 'p4 submit' commits integrated files
<br/> to the depot. Unresolved files may not be submitted. Integrations
<br/> can be shelved with 'p4 shelve' and abandoned with 'p4 revert'. The
<br/> commands 'p4 integrated' and 'p4 filelog' display integration history.
<br/>
<br/> When 'p4 integrate' schedules a workspace file to be resolved, it
<br/> leaves it read-only. 'p4 resolve' can operate on a read-only file.
<br/> For other pre-submit changes, 'p4 edit' must be used to make the
<br/> file writable.
<br/>
<br/> Source and target files can be specified either on the 'p4 integrate'
<br/> command line or through a branch view. On the command line, fromFile
<br/> is the source file set and toFile is the target file set. With a
<br/> branch view, one or more toFile arguments can be given to limit the
<br/> scope of the target file set.
<br/>
<br/> revRange is a revision or a revision range that limits the span of
<br/> source history to be probed for unintegrated revisions. revRange
<br/> can be used on fromFile, or on toFile, but not on both. When used on
<br/> toFile, it refers to source revisions, not to target revisions. For
<br/> details about revision specifiers, see 'p4 help revisions'.
<br/>
<br/> The -S flag makes 'p4 integrate' use a generated branch view that maps
<br/> a stream (or its underlying real stream) to its parent. With -r, the
<br/> direction of the mapping is reversed. -P can be used to generate the
<br/> branch view using a parent stream other than the stream's actual
<br/> parent. Note that to submit integrated stream files, the current
<br/> client must be switched to the target stream, or to a virtual child
<br/> stream of the target stream.
<br/>
<br/> The -b flag makes 'p4 integrate' use a user-defined branch view.
<br/> (See 'p4 help branch'.) The source is the left side of the branch view
<br/> and the target is the right side. With -r, the direction is reversed.
<br/>
<br/> The -s flag can be used with -b to cause fromFile to be treated as
<br/> the source, and both sides of the branch view to be treated as the
<br/> target, per the branch view mapping. Optional toFile arguments may
<br/> be given to further restrict the scope of the target file set. The
<br/> -r flag is ignored when -s is used.
<br/>
<br/> Note that 'p4 integrate' automatically adusts source-to-target
<br/> mappings for moved and renamed files. (Adjustment occurs only if
<br/> the 'p4 move' command was used to move/rename files.) The scope of
<br/> source and target file sets must include both the old-named and the
<br/> new-named files for mappings to be adjusted. A filename resolve is
<br/> scheduled for each remapped file to allow the target to be moved to
<br/> match the source.
<br/>
<br/> The -f flag forces integrate to ignore integration history and treat
<br/> all source revisions as unintegrated. It is meant to be used with
<br/> revRange to force reintegration of specific, previously integrated
<br/> revisions.
<br/>
<br/> The -O flags cause more information to be output for each file opened:
<br/>
<br/> -Ob Show the base revision for the merge (if any).
<br/> -Or Show the resolve(s) that are being scheduled.
<br/>
<br/> The -R flags modify the way resolves are scheduled:
<br/>
<br/> -Rb Schedules 'branch resolves' instead of branching new
<br/> target files automatically.
<br/>
<br/> -Rd Schedules 'delete resolves' instead of deleting
<br/> target files automatically.
<br/>
<br/> -Rs Skips cherry-picked revisions already integrated.
<br/> This can improve merge results, but can also cause
<br/> multiple resolves per file to be scheduled.
<br/>
<br/> The -Di flag modifies the way deleted revisions are treated. If the
<br/> source file has been deleted and re-added, revisions that precede
<br/> the deletion will be considered to be part of the same source file.
<br/> By default, re-added files are considered to be unrelated to the
<br/> files of the same name that preceded them.
<br/>
<br/> The -h flag leaves the target files at the revision currently synced
<br/> to the client (the '#have' revision). By default, target files are
<br/> automatically synced to the head revision by 'p4 integrate'.
<br/>
<br/> The -m flag limits integration to the first 'max' number of files.
<br/>
<br/> The -n flag displays a preview of integration, without actually
<br/> doing anything.
<br/>
<br/> The -q flag suppresses normal output messages. Messages regarding
<br/> errors or exceptional conditions are displayed.
<br/>
<br/> If -c changelist# is specified, the files are opened in the
<br/> designated numbered pending changelist instead of the 'default'
<br/> changelist.
<br/>
<br/> The -v flag causes a 'virtual' integration that does not modify
<br/> client workspace files unless target files need to be resolved.
<br/> After submitting a virtual integration, 'p4 sync' can be used to
<br/> update the workspace.
<br/>
<br/> Integration is not supported for files with propagating attributes
<br/> from an edge server in a distributed environment. Depending on the
<br/> integration action, target, and source, either the integration or
<br/> resolve command will fail.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Options.#ctor(Perforce.P4.LabelSyncCmdFlags)">
<summary>
Options for the labelsync command.
</summary>
<param name="flags"></param>
<param name="labelName"></param>
<returns></returns>
<remarks>
<br/><b>p4 help labelsync</b>
<br/>
<br/> labelsync -- Apply the label to the contents of the client workspace
<br/>
<br/> p4 labelsync [-a -d -g -n -q] -l label [file[revRange] ...]
<br/>
<br/> Labelsync causes the specified label to reflect the current contents
<br/> of the client. It records the revision of each file currently synced.
<br/> The label's name can subsequently be used in a revision specification
<br/> as @label to refer to the revision of a file as stored in the label.
<br/>
<br/> Without a file argument, labelsync causes the label to reflect the
<br/> contents of the whole client, by adding, deleting, and updating the
<br/> label. If a file is specified, labelsync updates the specified file.
<br/>
<br/> If the file argument includes a revision specification, that revision
<br/> is used instead of the revision synced by the client. If the specified
<br/> revision is a deleted revision, the label includes that deleted
<br/> revision. See 'p4 help revisions' for details about specifying
<br/> revisions.
<br/>
<br/> If the file argument includes a revision range specification,
<br/> only files selected by the revision range are updated, and the
<br/> highest revision in the range is used.
<br/>
<br/> The -a flag adds the specified file to the label.
<br/>
<br/> The -d deletes the specified file from the label, regardless of
<br/> revision.
<br/>
<br/> The -n flag previews the operation without altering the label.
<br/>
<br/> Only the owner of a label can run labelsync on that label. A label
<br/> that has its Options: field set to 'locked' cannot be updated. A
<br/> label without an owner can be labelsync'd by any user.
<br/>
<br/> The -q flag suppresses normal output messages. Messages regarding
<br/> errors or exceptional conditions are displayed.
<br/>
<br/> The -g flag should be used on an Edge Server to update a global
<br/> label. Note that in this case, the client should be a global client.
<br/> Configuring rpl.labels.global=1 reverses this default and causes this
<br/> flag to have the opposite meaning.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Options.#ctor(System.Int32)">
<summary>
Options for the lock command.
</summary>
<param name="changeList"></param>
<returns></returns>
<remarks>
<br/><b>p4 help lock</b>
<br/>
<br/> lock -- Lock an open file to prevent it from being submitted
<br/>
<br/> p4 lock [-c changelist#] [file ...]
<br/>
<br/> The specified files are locked in the depot, preventing any user
<br/> other than the current user on the current client from submitting
<br/> changes to the files. If a file is already locked, the lock request
<br/> is rejected. If no file names are specified, all files in the
<br/> specified changelist are locked. If changelist number is omitted,
<br/> files in the default changelist are locked.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Options.#ctor(Perforce.P4.MoveFileCmdFlags,System.Int32,Perforce.P4.FileType)">
<summary>
Options for the move command.
</summary>
<param name="flags"></param>
<param name="changeList"></param>
<param name="fileType"></param>
<returns></returns>
<remarks>
<br/><b>p4 help move</b>
<br/>
<br/> move -- move file(s) from one location to another
<br/> rename -- synonym for 'move'
<br/>
<br/> p4 move [-c changelist#] [-f -n -k] [-t filetype] fromFile toFile
<br/>
<br/> Move takes an already opened file and moves it from one client
<br/> location to another, reopening it as a pending depot move. When
<br/> the file is submitted with 'p4 submit', its depot file is moved
<br/> accordingly.
<br/>
<br/> Wildcards in fromFile and toFile must match. The fromFile must be
<br/> a file open for add or edit.
<br/>
<br/> 'p4 opened' lists pending moves. 'p4 diff' can compare a moved
<br/> client file with its depot original, 'p4 sync' can schedule an
<br/> update of a moved file, and 'p4 resolve' can resolve the update.
<br/>
<br/> A client file can be moved many times before it is submitted.
<br/> Moving a file back to its original location will undo a pending
<br/> move, leaving unsubmitted content intact. Using 'p4 revert'
<br/> undoes the move and reverts the unsubmitted content.
<br/>
<br/> If -c changelist# is specified, the file is reopened in the
<br/> specified pending changelist as well as being moved.
<br/>
<br/> The -f flag forces a move to an existing target file. The file
<br/> must be synced and not opened. The originating source file will
<br/> no longer be synced to the client.
<br/>
<br/> If -t filetype is specified, the file is assigned that filetype.
<br/> If the filetype is a partial filetype, the partial filetype is
<br/> combined with the current filetype. See 'p4 help filetypes'.
<br/>
<br/> The -n flag previews the operation without moving files.
<br/>
<br/> The -k flag performs the rename on the server without modifying
<br/> client files. Use with caution, as an incorrect move can cause
<br/> discrepancies between the state of the client and the corresponding
<br/> server metadata.
<br/>
<br/> The 'move' command requires a release 2009.1 or newer client. The
<br/> '-f' flag requires a 2010.1 client.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Options.#ctor(System.Int32,Perforce.P4.FileType)">
<summary>
Options for the reopen command.
</summary>
<param name="changeList"></param>
<param name="fileType"></param>
<returns></returns>
<remarks>
<br/><b>p4 help reopen</b>
<br/>
<br/> reopen -- Change the filetype of an open file or move it to
<br/> another changelist
<br/>
<br/> p4 reopen [-c changelist#] [-t filetype] file ...
<br/>
<br/> Reopen an open file for the current user in order to move it to a
<br/> different changelist or change its filetype.
<br/>
<br/> The target changelist must exist; you cannot create a changelist by
<br/> reopening a file. To move a file to the default changelist, use
<br/> 'p4 reopen -c default'.
<br/>
<br/> If -t filetype is specified, the file is assigned that filetype. If
<br/> a partial filetype is specified, it is combined with the current
<br/> filetype. For details, see 'p4 help filetypes'.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Options.#ctor(Perforce.P4.ResolveFilesCmdFlags,System.Int32)">
<summary>
Options for the resolve command
</summary>
<param name="flags"></param>
<param name="changeList"></param>
<remarks>
<br/><b>p4 help resolve</b>
<br/>
<br/> resolve -- Resolve integrations and updates to workspace files
<br/>
<br/> p4 resolve [options] [file ...]
<br/>
<br/> options: -A<flags> -a<flags> -d<flags> -f -n -N -o -t -v
<br/> -c changelist#
<br/>
<br/> 'p4 resolve' resolves changes to files in the client workspace.
<br/>
<br/> 'p4 resolve' works only on files that have been scheduled to be
<br/> resolved. The commands that can schedule resolves are: 'p4 sync',
<br/> 'p4 update', 'p4 submit', 'p4 merge', and 'p4 integrate'. Files must
<br/> be resolved before they can be submitted.
<br/>
<br/> Resolving involves two sets of files, a source and a target. The
<br/> target is a set of depot files that maps to opened files in the
<br/> client workspace. When resolving an integration, the source is a
<br/> different set of depot files than the target. When resolving an
<br/> update, the source is the same set of depot files as the target,
<br/> at a different revision.
<br/>
<br/> The 'p4 resolve' file argument specifies the target. If the file
<br/> argument is omitted, all unresolved files are resolved.
<br/>
<br/> Resolving can modify workspace files. To back up files, use 'p4
<br/> shelve' before using 'p4 resolve'.
<br/>
<br/> The resolve process is a classic three-way merge. The participating
<br/> files are referred to as follows:
<br/>
<br/> 'yours' The target file open in the client workspace
<br/> 'theirs' The source file in the depot
<br/> 'base' The common ancestor; the highest revision of the
<br/> source file already accounted for in the target.
<br/> 'merged' The merged result.
<br/>
<br/> Filenames, filetypes, and text file content can be resolved by
<br/> accepting 'yours', 'theirs', or 'merged'. Branching, deletion, and
<br/> binary file content can be resolved by accepting either 'yours' or
<br/> 'theirs'.
<br/>
<br/> When resolving integrated changes, 'p4 resolve' distinguishes among
<br/> four results: entirely yours, entirely theirs, a pure merge, or an
<br/> edited merge. The distinction is recorded when resolved files are
<br/> submitted, and will be used by future commands to determine whether
<br/> integration is needed.
<br/>
<br/> In all cases, accepting 'yours' leaves the target file in its current
<br/> state. The result of accepting 'theirs' is as follows:
<br/>
<br/> Content: The target file content is overwritten.
<br/> Attribute: The target's attributes are replaced.
<br/> Branching: A new target is branched.
<br/> Deletion: The target file is deleted.
<br/> Filename: The target file is moved or renamed.
<br/> Filetype: The target file's type is changed.
<br/>
<br/> For each unresolved change, the user is prompted to accept a result.
<br/> Content and non-content changes are resolved separately. For content,
<br/> 'p4 resolve' places the merged result into a temporary file in the
<br/> client workspace. If there are any conflicts, the merged file contains
<br/> conflict markers that must be removed by the user.
<br/>
<br/> 'p4 resolve' displays a count of text diffs and conflicts, and offers
<br/> the following prompts:
<br/>
<br/> Accept:
<br/> at Keep only changes to their file.
<br/> ay Keep only changes to your file.
<br/> * am Keep merged file.
<br/> * ae Keep merged and edited file.
<br/> * a Keep autoselected file.
<br/>
<br/> Diff:
<br/> * dt See their changes alone.
<br/> * dy See your changes alone.
<br/> * dm See merged changes.
<br/> d Diff your file against merged file.
<br/>
<br/> Edit:
<br/> et Edit their file (read only).
<br/> ey Edit your file (read/write).
<br/> * e Edit merged file (read/write).
<br/>
<br/> Misc:
<br/> * m Run '$P4MERGE base theirs yours merged'.
<br/> (Runs '$P4MERGEUNICODE charset base theirs
<br/> yours merged' if set and the file is a
<br/> unicode file.)
<br/> s Skip this file.
<br/> h Print this help message.
<br/> ^C Quit the resolve operation.
<br/>
<br/> Options marked (*) appear only for text files. The suggested action
<br/> will be displayed in brackets.
<br/>
<br/> The 'merge' (m) option enables you to invoke your own merge program, if
<br/> one is configured using the $P4MERGE environment variable. Four files
<br/> are passed to the program: the base, yours, theirs, and the temporary
<br/> file. The program is expected to write merge results to the temporary
<br/> file.
<br/>
<br/> The -A flag can be used to limit the kind of resolving that will be
<br/> attempted; without it, everything is attempted:
<br/>
<br/> -Aa Resolve attributes.
<br/> -Ab Resolve file branching.
<br/> -Ac Resolve file content changes.
<br/> -Ad Resolve file deletions.
<br/> -Am Resolve moved and renamed files.
<br/> -At Resolve filetype changes.
<br/> -AQ Resolve charset changes.
<br/>
<br/> The -a flag puts 'p4 resolve' into automatic mode. The user is not
<br/> prompted, and files that can't be resolved automatically are skipped:
<br/>
<br/> -as 'Safe' resolve; skip files that need merging.
<br/> -am Resolve by merging; skip files with conflicts.
<br/> -af Force acceptance of merged files with conflicts.
<br/> -at Force acceptance of theirs; overwrites yours.
<br/> -ay Force acceptance of yours; ignores theirs.
<br/>
<br/> The -as flag causes the workspace file to be replaced with their file
<br/> only if theirs has changed and yours has not.
<br/>
<br/> The -am flag causes the workspace file to be replaced with the result
<br/> of merging theirs with yours. If the merge detected conflicts, the
<br/> file is left untouched and unresolved.
<br/>
<br/> The -af flag causes the workspace file to be replaced with the result
<br/> of merging theirs with yours, even if there were conflicts. This can
<br/> leave conflict markers in workspace files.
<br/>
<br/> The -at flag resolves all files by copying theirs into yours. It
<br/> should be used with care, as it overwrites any changes made to the
<br/> file in the client workspace.
<br/>
<br/> The -ay flag resolves all files by accepting yours and ignoring
<br/> theirs. It preserves the content of workspace files.
<br/>
<br/> The -d flags can be used to control handling of whitespace and line
<br/> endings when merging files:
<br/>
<br/> -db Ignore whitespace changes.
<br/> -dw Ignore whitespace altogether.
<br/> -dl Ignores line endings.
<br/>
<br/> The -d flags are also passed to the diff options in the 'p4 resolve'
<br/> dialog. Additional -d flags that modify the diff output but do not
<br/> modify merge behavior include -dn (RCS), -dc (context), -ds (summary),
<br/> and -du (unified). Note that 'p4 resolve' uses text from the client
<br/> file if the files differ only in whitespace.
<br/>
<br/> The -f flag enables previously resolved content to be resolved again.
<br/> By default, after files have been resolved, 'p4 resolve' does not
<br/> process them again.
<br/>
<br/> The -n flag previews the operation without altering files.
<br/>
<br/> The -N flag previews the operation with additional information about
<br/> any non-content resolve actions that are scheduled.
<br/>
<br/> The -o flag displays the base file name and revision to be used
<br/> during the the merge.
<br/>
<br/> The -t flag forces 'p4 resolve' to attempt a textual merge, even for
<br/> files with non-text (binary) types.
<br/>
<br/> The -v flag causes 'p4 resolve' to insert markers for all changes,
<br/> not just conflicts.
<br/>
<br/> The -c flag limits 'p4 resolve' to the files in changelist#.
<br/>
<br/> 'p4 resolve' is not supported for files with propagating attributes
<br/> from an edge server in a distributed environment.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Options.#ctor(Perforce.P4.SubmitFilesCmdFlags,System.Int32,Perforce.P4.Changelist,System.String,Perforce.P4.ClientSubmitOptions)">
<summary>
Submit command options
</summary>
<param name="flags"></param>
<param name="changelist"></param>
<param name="newChangelist"></param>
<param name="description"></param>
<param name="submitOptions"></param>
<returns></returns>
<remarks>
<br/><b>p4 help submit</b>
<br/>
<br/> submit -- Submit open files to the depot
<br/>
<br/> p4 submit [-r -s -f option --noretransfer 0|1]
<br/> p4 submit [-r -s -f option] file
<br/> p4 submit [-r -f option] -d description
<br/> p4 submit [-r -f option] -d description file
<br/> p4 submit [-r -f option --noretransfer 0|1] -c changelist#
<br/> p4 submit -e shelvedChange#
<br/> p4 submit -i [-r -s -f option]
<br/> --parallel=threads=N[,batch=N][,min=N]
<br/>
<br/> 'p4 submit' commits a pending changelist and its files to the depot.
<br/>
<br/> By default, 'p4 submit' attempts to submit all files in the 'default'
<br/> changelist. Submit displays a dialog where you enter a description
<br/> of the change and, optionally, delete files from the list of files
<br/> to be checked in.
<br/>
<br/> To add files to a changelist before submitting, use any of the
<br/> commands that open client workspace files: 'p4 add', 'p4 edit',
<br/> etc.
<br/>
<br/> If the file parameter is specified, only files in the default
<br/> changelist that match the pattern are submitted.
<br/>
<br/> Files in a stream path can be submitted only by client workspaces
<br/> dedicated to the stream. See 'p4 help client'.
<br/>
<br/> Before committing a changelist, 'p4 submit' locks all the files being
<br/> submitted. If any file cannot be locked or submitted, the files are
<br/> left open in a numbered pending changelist. By default, the files in
<br/> a failed submit operation are left locked unless the
<br/> submit.unlocklocked configurable is set. Files are unlocked even if
<br/> they were manually locked prior to submit if submit fails when
<br/> submit.unlocklocked is set. 'p4 opened' shows unsubmitted files
<br/> and their changelists.
<br/>
<br/> Submit is atomic: if the operation succeeds, all files are updated
<br/> in the depot. If the submit fails, no depot files are updated.
<br/>
<br/> If submit fails, some or all of the files may have been copied to
<br/> the server. By default, retrying a failed submit will transfer all of
<br/> the files again unless the submit.noretransfer configurable is set.
<br/> If submit.noretransfer is set to 1, submit uses digest comparisons to
<br/> to detect if the files have already been transferred in order to
<br/> avoid file re-transfer when retrying a failed submit.
<br/>
<br/> The --noretransfer flag is used to override the submit.noretransfer
<br/> configurable so the user can choose his preferred re-transfer
<br/> behavior during the current submit operation.
<br/>
<br/> The -c flag submits the specified pending changelist instead of the
<br/> default changelist. Additional changelists can be created manually,
<br/> using the 'p4 change' command, or automatically as the result of a
<br/> failed attempt to submit the default changelist.
<br/>
<br/> The -e flag submits a shelved changelist without transferring files
<br/> or modifying the workspace. The shelved change must be owned by
<br/> the person submitting the change, but the client may be different.
<br/> However, files shelved to a stream target may only be submitted by
<br/> a stream client that is mapped to the target stream. In addition,
<br/> files shelved to a non-stream target cannot be submitted by a stream
<br/> client. To submit a shelved change, all files in the shelved change
<br/> must be up to date and resolved. No files may be open in any workspace
<br/> at the same change number. Client submit options (ie revertUnchanged,
<br/> etc) will be ignored. If the submit is successful, the shelved change
<br/> and files are cleaned up, and are no longer available to be unshelved
<br/> or submitted.
<br/>
<br/> The -d flag passes a description into the specified changelist rather
<br/> than displaying the changelist dialog for manual editing. This option
<br/> is useful for scripting, but does not allow you to add jobs or modify
<br/> the default changelist.
<br/>
<br/> The -f flag enables you to override submit options that are configured
<br/> for the client that is submitting the changelist. This flag overrides
<br/> the -r (reopen)flag, if it is specified. See 'p4 help client' for
<br/> details about submit options.
<br/>
<br/> The -i flag reads a changelist specification from the standard input.
<br/> The user's editor is not invoked.
<br/>
<br/> The -r flag reopens submitted files in the default changelist after
<br/> submission.
<br/>
<br/> The -s flag extends the list of jobs to include the fix status
<br/> for each job, which becomes the job's status when the changelist
<br/> is committed. See 'p4 help change' for details.
<br/>
<br/> The --parallel flag specifies options for parallel file transfer. If
<br/> parallel file transfer has been enabled by setting the
<br/> net.parallel.max configurable, and if there are sufficient resources
<br/> across the system, a submit command may execute more rapidly by
<br/> transferring multiple files in parallel. Specify threads=N to request
<br/> files be sent concurrently, using N independent network connections.
<br/> The N threads grab work in batches; specify batch=N to control the
<br/> number of files in a batch. A submit that is too small will not
<br/> initiate parallel file transfers; specify min=N to control the
<br/> minimum number of files in a parallel submit. Requesting progress
<br/> indicators causes the --parallel flag to be ignored.
<br/>
<br/> Using --parallel from an edge server allows parallel file transfer
<br/> from the edge server to the commit server. This uses standard pull
<br/> threads to transfer the files. Note that an adminstrator must insure
<br/> that pull threads can be run on the commit server. The address
<br/> used by the commit server to connect to the edge server must
<br/> be specified in the ExternalAddress field of the edge server spec.
<br/>
<br/> Only 'submit -e' is supported for files with propagating attributes
<br/> from an edge server in a distributed environment.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Options.#ctor(Perforce.P4.GetResolvedFilesCmdFlags)">
<summary>
Resolved command options.
</summary>
<param name="flags"></param>
<returns></returns>
<remarks>
<br/><b>p4 help resolved</b>
<br/>
<br/> resolved -- Show files that have been resolved but not submitted
<br/>
<br/> p4 resolved [-o] [file ...]
<br/>
<br/> 'p4 resolved' lists file updates and integrations that have been
<br/> resolved but not yet submitted. To see unresolved integrations,
<br/> use 'p4 resolve -n'. To see already submitted integrations, use
<br/> 'p4 integrated'.
<br/>
<br/> If a depot file path is specified, the output lists resolves for
<br/> 'theirs' files that match the specified path. If a client file
<br/> path is specified, the output lists resolves for 'yours' files
<br/> that match the specified path.
<br/>
<br/> The -o flag reports the revision used as the base during the
<br/> resolve.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Options.#ctor(Perforce.P4.RevertFilesCmdFlags,System.Int32)">
<summary>
Revert command options.
</summary>
<param name="flags"></param>
<param name="changelist"></param>
<returns></returns>
<remarks>
<br/><b>p4 help revert</b>
<br/>
<br/> revert -- Discard changes from an opened file
<br/>
<br/> p4 revert [-a -n -k -w -c changelist# -C client] file ...
<br/>
<br/> Revert an open file to the revision that was synced from the depot,
<br/> discarding any edits or integrations that have been made. You must
<br/> explicitly specify the files to be reverted. Files are removed from
<br/> the changelist in which they are open. Locked files are unlocked.
<br/>
<br/> The -a flag reverts only files that are open for edit, add, or
<br/> integrate and are unchanged or missing. Files with pending
<br/> integration records are left open. The file arguments are optional
<br/> when -a is specified.
<br/>
<br/> The -n flag displays a preview of the operation.
<br/>
<br/> The -k flag marks the file as reverted in server metadata without
<br/> altering files in the client workspace.
<br/>
<br/> The -w flag causes files that are open for add to be deleted from the
<br/> workspace when they are reverted.
<br/>
<br/> The -c flag reverts files that are open in the specified changelist.
<br/>
<br/> The -C flag allows a user to specify the workspace that has the file
<br/> opened rather than defaulting to the current client workspace. When
<br/> this option is used, the '-k' flag is also enabled and the check for
<br/> matching user is disabled. The -C flag requires 'admin' access, which
<br/> is granted by 'p4 protect'.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Options.#ctor(Perforce.P4.ShelveFilesCmdFlags,Perforce.P4.Changelist,System.Int32)">
<summary>
Shelve command options.
</summary>
<param name="flags"></param>
<param name="newChangelist"></param>
<param name="changelistId"></param>
<returns></returns>
<remarks>
<br/><b>p4 help shelve</b>
<br/>
<br/> shelve -- Store files from a pending changelist into the depot
<br/>
<br/> p4 shelve [-p] [files]
<br/> p4 shelve [-a option] [-p] -i [-f | -r]
<br/> p4 shelve [-a option] [-p] -r -c changelist#
<br/> p4 shelve [-a option] [-p] -c changelist# [-f] [file ...]
<br/> p4 shelve -d -c changelist# [-f] [file ...]
<br/>
<br/> 'p4 shelve' creates, modifies or deletes shelved files in a pending
<br/> changelist. Shelved files remain in the depot until they are deleted
<br/> (using 'p4 shelve -d') or replaced by subsequent shelve commands.
<br/> After 'p4 shelve', the user can revert the files and restore them
<br/> later using 'p4 unshelve'. Other users can 'p4 unshelve' the stored
<br/> files into their own workspaces.
<br/>
<br/> Files that have been shelved can be accessed by the 'p4 diff',
<br/> 'p4 diff2', 'p4 files' and 'p4 print' commands using the revision
<br/> specification '@=change', where 'change' is the pending changelist
<br/> number.
<br/>
<br/> By default, 'p4 shelve' creates a changelist, adds files from the
<br/> user's default changelist, then shelves those files in the depot.
<br/> The user is presented with a text changelist form displayed using
<br/> the editor configured using the $P4EDITOR environment variable.
<br/>
<br/> If a file pattern is specified, 'p4 shelve' shelves the files that
<br/> match the pattern.
<br/>
<br/> The -i flag reads the pending changelist specification with shelved
<br/> files from the standard input. The user's editor is not invoked.
<br/> To modify an existing changelist with shelved files, specify the
<br/> changelist number using the -c flag.
<br/>
<br/> The -c flag specifies the pending changelist that contains shelved
<br/> files to be created, deleted, or modified. Only the user and client
<br/> of the pending changelist can add or modify its shelved files. Any
<br/> files specified by the file pattern must already be opened in the
<br/> specified changelist; use 'p4 reopen' to move an opened file from
<br/> one changelist to another.
<br/>
<br/> The -f (force) flag must be used with the -c or -i flag to overwrite
<br/> any existing shelved files in a pending changelist.
<br/>
<br/> The -r flag (used with -c or -i) enables you to replace all shelved
<br/> files in that changelist with the files opened in your own workspace
<br/> at that changelist number. Previously shelved files will be deleted.
<br/> Only the user and client workspace of the pending changelist can
<br/> replace its shelved files.
<br/>
<br/> The -a flag enables you to handle unchanged files similarly to some
<br/> client submit options, namely 'submitunchanged' and 'leaveunchanged'.
<br/> The default behavior of shelving all files corresponds to the
<br/> 'submitunchanged' option. The 'leaveunchanged' option only shelves
<br/> changed files, and then leaves the files opened in the pending
<br/> changelist on the client.
<br/>
<br/> The -d flag (used with -c) deletes the shelved files in the specified
<br/> changelist so that they can no longer be unshelved. By default, only
<br/> the user and client of the pending changelist can delete its shelved
<br/> files. A user with 'admin' access can delete shelved files by including
<br/> the -f flag to force the operation.
<br/>
<br/> The -p flag promotes a shelved change from an edge server to a commit
<br/> server where it can be accessed by other edge servers participating
<br/> in the distributed configuration. Once a shelved change has been
<br/> promoted, all subsequent local modifications to the shelf are also
<br/> pushed to the commit server and remain until the shelf is deleted.
<br/> Once a shelf has been created, the combination of flags '-p -c' will
<br/> promote the shelf without modification unless '-f' or '-r' are also
<br/> used to update the shelved files before promotion.
<br/>
<br/> 'p4 shelve' is not supported for files with propagating attributes
<br/> from an edge server in a distributed environment.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Options.#ctor(Perforce.P4.SyncFilesCmdFlags,System.Int32)">
<summary>
Sync command options.
</summary>
<param name="flags"></param>
<param name="maxItems"></param>
<remarks>
<br/><b>p4 help sync</b>
<br/>
<br/> sync -- Synchronize the client with its view of the depot
<br/> flush -- synonym for 'sync -k'
<br/> update -- synonym for 'sync -s'
<br/>
<br/> p4 sync [-f -L -n -N -k -q -r] [-m max] [file[revRange] ...]
<br/> p4 sync [-L -n -N -q -s] [-m max] [file[revRange] ...]
<br/> p4 sync [-L -n -N -p -q] [-m max] [file[revRange] ...]
<br/> --parallel=threads=N[,batch=N][,batchsize=N][,min=N][,minsize=N]
<br/>
<br/> Sync updates the client workspace to reflect its current view (if
<br/> it has changed) and the current contents of the depot (if it has
<br/> changed). The client view maps client and depot file names and
<br/> locations.
<br/>
<br/> Sync adds files that are in the client view and have not been
<br/> retrieved before. Sync deletes previously retrieved files that
<br/> are no longer in the client view or have been deleted from the
<br/> depot. Sync updates files that are still in the client view and
<br/> have been updated in the depot.
<br/>
<br/> By default, sync affects all files in the client workspace. If file
<br/> arguments are given, sync limits its operation to those files.
<br/> The file arguments can contain wildcards.
<br/>
<br/> If the file argument includes a revision specifier, then the given
<br/> revision is retrieved. Normally, the head revision is retrieved.
<br/> See 'p4 help revisions' for help specifying revisions.
<br/>
<br/> If the file argument includes a revision range specification,
<br/> only files selected by the revision range are updated, and the
<br/> highest revision in the range is used.
<br/>
<br/> Normally, sync does not overwrite workspace files that the user has
<br/> manually made writable. Setting the 'clobber' option in the
<br/> client specification disables this safety check.
<br/>
<br/> The -f flag forces resynchronization even if the client already
<br/> has the file, and overwriting any writable files. This flag doesn't
<br/> affect open files.
<br/>
<br/> The -L flag can be used with multiple file arguments that are in
<br/> full depot syntax and include a valid revision number. When this
<br/> flag is used the arguments are processed together by building an
<br/> internal table similar to a label. This file list processing is
<br/> significantly faster than having to call the internal query engine
<br/> for each individual file argument. However, the file argument syntax
<br/> is strict and the command will not run if an error is encountered.
<br/>
<br/> The -n flag previews the operation without updating the workspace.
<br/>
<br/> The -N flag also previews the operation without updating the
<br/> workspace, but reports only a summary of the work the sync would do.
<br/>
<br/> The -k flag updates server metadata without syncing files. It is
<br/> intended to enable you to ensure that the server correctly reflects
<br/> the state of files in the workspace while avoiding a large data
<br/> transfer. Caution: an erroneous update can cause the server to
<br/> incorrectly reflect the state of the workspace.
<br/>
<br/> The -p flag populates the client workspace, but does not update the
<br/> server to reflect those updates. Any file that is already synced or
<br/> opened will be bypassed with a warning message. This option is very
<br/> useful for build clients or when publishing content without the
<br/> need to track the state of the client workspace.
<br/>
<br/> The -q flag suppresses normal output messages. Messages regarding
<br/> errors or exceptional conditions are not suppressed.
<br/>
<br/> The -r flag allows open files which are mapped to new locations
<br/> in the depot to be reopened in the new location. By default, open
<br/> workspace files remain associated with the depot files that they were
<br/> originally opened as.
<br/>
<br/> The -s flag adds a safety check before sending content to the client
<br/> workspace. This check uses MD5 digests to compare the content on the
<br/> clients workspace against content that was last synced. If the file
<br/> has been modified outside of Perforce's control then an error message
<br/> is displayed and the file is not overwritten. This check adds some
<br/> extra processing which will affect the performance of the operation.
<br/> Clients with 'allwrite' and 'noclobber' set do this check by default.
<br/>
<br/> The -m flag limits sync to the first 'max' number of files. This
<br/> option is useful in conjunction with tagged output and the '-n'
<br/> flag, to preview how many files will be synced without transferring
<br/> all the file data.
<br/>
<br/> The --parallel flag specifies options for parallel file transfer. If
<br/> your administrator has enabled parallel file transfer by setting the
<br/> net.parallel.max configurable, and if there are sufficient resources
<br/> across the system, a sync command may execute more rapidly by
<br/> transferring multiple files in parallel. Specify threads=N to request
<br/> files be sent concurrently, using N independent network connections.
<br/> The N threads grab work in batches; specify batch=N to control the
<br/> number of files in a batch, or batchsize=N to control the number of
<br/> bytes in a batch. A sync that is too small will not initiate parallel
<br/> file transfers; specify min=N to control the minimum number of files
<br/> in a parallel sync, or minsize=N to control the minimum number of
<br/> bytes in a parallel sync. Requesting progress indicators causes the
<br/> --parallel flag to be ignored.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Options.#ctor(Perforce.P4.UnlockFilesCmdFlags,System.Int32)">
<summary>
Unlock command options.
</summary>
<param name="flags"></param>
<param name="changelistId"></param>
<returns></returns>
<remarks>
<br/><b>p4 help unlock</b>
<br/>
<br/> unlock -- Release a locked file, leaving it open
<br/>
<br/> p4 unlock [-c | -s changelist# | -x] [-f] [file ...]
<br/> p4 -c client unlock [-f] -r
<br/>
<br/> 'p4 unlock' releases locks on the specified files, which must be
<br/> open in the specified pending changelist. If you omit the changelist
<br/> number, the default changelist is assumed. If you omit the file name,
<br/> all locked files are unlocked.
<br/>
<br/> The -s flag unlocks files from a shelved changelist caused by an
<br/> aborted 'submit -e' operation. The -c flag applies to opened files
<br/> in a pending changelist locked by 'p4 lock' or by a failed submit
<br/> of a change that is not shelved.
<br/>
<br/> By default, files can be unlocked only by the changelist owner who
<br/> must also be the person who has the files locked. The -f flag
<br/> enables you to unlock files in changelists owned by other users.
<br/> The -f flag requires 'admin' access, which is granted by 'p4
<br/> protect'.
<br/>
<br/> The -x option unlocks files that are opened 'exclusive' but are
<br/> orphaned (see 'p4 opened -x'). This option only applies to a
<br/> distributed installation where global tracking of these file types
<br/> is necessary across servers.
<br/>
<br/> If a push command from a remote server to this server fails, files
<br/> can be left locked on this server, preventing other users from
<br/> submitting changes to those files. In this case, the user who issued
<br/> the push command can specify the -r flag with the name of the client
<br/> that was used on that remote server to unlock the files on this
<br/> server. An administrator can run 'unlock -f -r' as well.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Options.#ctor(Perforce.P4.UnshelveFilesCmdFlags,System.Int32,System.Int32)">
<summary>
Unshelve command options.
</summary>
<param name="flags"></param>
<param name="changelistId"></param>
<param name="newChangelistId"></param>
<returns></returns>
<remarks>
<br/><b>p4 help unshelve</b>
<br/>
<br/> unshelve -- Restore shelved files from a pending change into a workspace
<br/>
<br/> p4 unshelve -s changelist# [options] [file ...]
<br/> Options: [-f -n] [-c changelist#] [-b branch|-S stream [-P parent]]
<br/>
<br/> 'p4 unshelve' retrieves shelved files from the specified pending
<br/> changelist, opens them in a pending changelist and copies them
<br/> to the invoking user's workspace. Unshelving files from a pending
<br/> changelist is restricted by the user's permissions on the files.
<br/> A successful unshelve operation places the shelved files on the
<br/> user's workspace with the same open action and pending integration
<br/> history as if it had originated from that user and client.
<br/>
<br/> Unshelving a file over an already opened file is permitted if both
<br/> shelved file and opened file are opened for 'edit'. In a distributed
<br/> environment, an additional requirement is that the shelve was created
<br/> on the same edge server. After unshelving, the workspace file is
<br/> flagged as unresolved, and 'p4 resolve' must be run to resolve the
<br/> differences between the shelved file and the workspace file.
<br/>
<br/> Unshelving a file opened for 'add' when the file already exists
<br/> in the depot will result in the file being opened for edit. After
<br/> unshelving, the workspace file is flagged as unresolved, and
<br/> 'p4 resolve' must be run to resolve the differences between the
<br/> shelved file and the depot file at the head revision. Note that
<br/> unshelving a file opened for 'add' over an already opened file is
<br/> not supported.
<br/>
<br/> The -s flag specifies the number of the pending changelist that
<br/> contains the shelved files.
<br/>
<br/> If a file pattern is specified, 'p4 unshelve' unshelves files that
<br/> match the pattern.
<br/>
<br/> The -b flag specifies a branch spec that the shelved files will be
<br/> mapped through prior to being unshelved, allowing files to be shelved
<br/> in one branch and unshelved in another. As with unshelving into an
<br/> open file, it may be necessary to run 'p4 resolve'. In a distributed
<br/> environment, an additional requirement is that the shelve was created
<br/> on the same edge server.
<br/>
<br/> The -S flag uses a generated branch view to map the shelved files
<br/> between the specified stream and its parent stream. The -P flag
<br/> can be used to generate the view using a parent stream other than
<br/> the actual parent.
<br/>
<br/> The -c flag specifies the changelist to which files are unshelved.
<br/> By default, 'p4 unshelve' opens shelved files in the default
<br/> changelist.
<br/>
<br/> The -f flag forces the clobbering of any writeable but unopened files
<br/> that are being unshelved.
<br/>
<br/> The -n flag previews the operation without changing any files or
<br/> metadata.
<br/>
<br/> 'p4 unshelve' is not supported for files with propagating attributes
<br/> from an edge server in a distributed environment.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Options.#ctor(Perforce.P4.CopyFilesCmdFlags,System.String,System.String,System.String,System.Int32,System.Int32)">
<summary>
Copy command options.
</summary>
<param name="flags"></param>
<param name="branchName"></param>
<param name="streamName"></param>
<param name="parentStream"></param>
<param name="changelistId"></param>
<param name="maxItems"></param>
<returns></returns>
<remarks>
<br/><b>p4 help copy</b>
<br/>
<br/> copy -- Copy one set of files to another
<br/>
<br/> p4 copy [options] fromFile[rev] toFile
<br/> p4 copy [options] -b branch [-r] [toFile[rev] ...]
<br/> p4 copy [options] -b branch -s fromFile[rev] [toFile ...]
<br/> p4 copy [options] -S stream [-P parent] [-F] [-r] [toFile[rev] ...]
<br/>
<br/> options: -c changelist# -f -n -v -m max -q
<br/>
<br/> 'p4 copy' copies one set of files (the 'source') into another (the
<br/> 'target').
<br/>
<br/> Using the client workspace as a staging area, 'p4 copy' makes the
<br/> target identical to the source by branching, replacing, or deleting
<br/> files. 'p4 submit' submits copied files to the depot. 'p4 revert'
<br/> can be used to revert copied files instead of submitting them. The
<br/> history of copied files can be shown with 'p4 filelog' or 'p4
<br/> integrated'.
<br/>
<br/> Target files that are already identical to the source, or that are
<br/> outside of the client view, are not affected by 'p4 copy'. Opened,
<br/> non-identical target files cause 'p4 copy' to exit with a warning.
<br/> When 'p4 copy' creates or modifies files in the workspace, it leaves
<br/> them read-only; 'p4 edit' can make them writable. Files opened by
<br/> 'p4 copy' do not need to be resolved.
<br/>
<br/> Source and target files (fromFile and toFile) can be specified on
<br/> the 'p4 copy' command line or through a branch view. On the command
<br/> line, fromFile is the source file set and toFile is the target file
<br/> set. With a branch view, one or more toFile arguments can be given
<br/> to limit the scope of the target file set.
<br/>
<br/> A revision specifier can be used to select the revision to copy; by
<br/> default, the head revision is copied. The revision specifier can be
<br/> used on fromFile, or on toFile, but not on both. When used on toFile,
<br/> it refers to source revisions, not to target revisions. A range may
<br/> not be used as a revision specifier. For revision syntax, see 'p4
<br/> help revisions'.
<br/>
<br/> The -S flag makes 'p4 copy' copy from a stream to its parent.
<br/> Use -r with -S to reverse the copy direction. Note that to submit
<br/> copied stream files, the current client must be switched to the
<br/> target stream, or to a virtual child stream of the target stream.
<br/> The -S flag causes 'p4 copy' to use a generated branch view that
<br/> maps the stream to its parent. -P can be used to generate the
<br/> branch view using a parent stream other than the stream's actual
<br/> parent. The -S flag also makes 'p4 copy' respect a stream's flow.
<br/>
<br/> The -F flag can be used with -S to force copying against a stream's
<br/> expected flow. It can also force -S to generate a branch view based
<br/> on a virtual stream; the mapping itself refers to the underlying
<br/> real stream.
<br/>
<br/> The -b flag makes 'p4 copy' use a user-defined branch view. (See
<br/> 'p4 help branch'.) The source is the left side of the branch view
<br/> and the target is the right side. With -r, the direction is reversed.
<br/>
<br/> The -s flag can be used with -b to cause fromFile to be treated as
<br/> the source, and both sides of the user-defined branch view to be
<br/> treated as the target, per the branch view mapping. Optional toFile
<br/> arguments may be given to further restrict the scope of the target
<br/> file set. -r is ignored when -s is used.
<br/>
<br/> The -c changelist# flag opens files in the designated (numbered)
<br/> pending changelist instead of the default changelist.
<br/>
<br/> The -f flag forces the creation of extra revisions in order to
<br/> explicitly record that files have been copied. Deleted source files
<br/> will be copied if they do not exist in the target, and files that are
<br/> already identical will be copied if they are not connected by existing
<br/> integration records.
<br/>
<br/> The -n flag displays a preview of the copy, without actually doing
<br/> anything.
<br/>
<br/> The -m flag limits the actions to the first 'max' number of files.
<br/>
<br/> The -q flag suppresses normal output messages. Messages regarding
<br/> errors or exceptional conditions are displayed.
<br/>
<br/> The -v flag causes a 'virtual' copy that does not modify client
<br/> workspace files. After submitting a virtual integration, 'p4 sync'
<br/> can be used to update the workspace.
<br/>
<br/> 'p4 copy' is not supported for files with propagating attributes
<br/> from an edge server in a distributed environment.
<br/>
<br/>
</remarks>
</member>
<!-- Badly formed XML comment ignored for member "M:Perforce.P4.Options.#ctor(Perforce.P4.MergeFilesCmdFlags,System.String,System.String,System.String,System.Int32,System.Int32)" -->
<member name="M:Perforce.P4.Options.#ctor(Perforce.P4.FixJobsCmdFlags,System.Int32,System.String)">
<summary>
Fix command options.
</summary>
<param name="flags"></param>
<param name="changelistId"></param>
<param name="status"></param>
<returns></returns>
<remarks>
<br/><b>p4 help fix</b>
<br/>
<br/> fix -- Mark jobs as being fixed by the specified changelist
<br/>
<br/> p4 fix [-d] [-s status] -c changelist# jobName ...
<br/>
<br/> 'p4 fix' marks each named job as being fixed by the changelist
<br/> number specified with -c. The changelist can be pending or
<br/> submitted and the jobs can be open or closed (fixed by another
<br/> changelist).
<br/>
<br/> If the changelist has already been submitted and the job is still
<br/> open, then 'p4 fix' marks the job closed. If the changelist has not
<br/> been submitted and the job is still open, the job is closed when the
<br/> changelist is submitted. If the job is already closed, it remains
<br/> closed.
<br/>
<br/> The -d flag deletes the specified fixes. This operation does not
<br/> otherwise affect the specified changelist or jobs.
<br/>
<br/> The -s flag uses the specified status instead of the default defined
<br/> in the job specification.
<br/>
<br/> The fix's status is reported by 'p4 fixes', and is related to the
<br/> job's status. Certain commands set the job's status to the fix's
<br/> status for each job associated with the change. When a job is fixed
<br/> by a submitted change, the job's status is set to match the fix
<br/> status. When a job is fixed by a pending change, the job's status
<br/> is set to match the fix status when the change is submitted. If the
<br/> fix's status is 'same', the job's status is left unchanged.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Options.#ctor(Perforce.P4.UserCmdFlags)">
<summary>
User command options.
</summary>
<param name="flags"></param>
<returns></returns>
<remarks>
<br/><b>p4 help user</b>
<br/>
<br/> user -- Create or edit a user specification
<br/>
<br/> p4 user [-f] [name]
<br/> p4 user -d [-f] name
<br/> p4 user -o [name]
<br/> p4 user -i [-f]
<br/>
<br/> Create a new user specification or edit an existing user specification.
<br/> The specification form is put into a temporary file and the editor
<br/> (configured by the environment variable $P4EDITOR) is invoked.
<br/>
<br/> Normally, a user specification is created automatically the first
<br/> time that the user issues any command that updates the depot. The
<br/> 'p4 user' command is typically used to edit the user's subscription
<br/> list for change review.
<br/>
<br/> The user specification form contains the following fields:
<br/>
<br/> User: The user name (read-only).
<br/>
<br/> Email: The user's email address (Default: user@client).
<br/>
<br/> Update: The date the specification was last modified (read-only).
<br/>
<br/> Access: The date that the user last issued a client command.
<br/>
<br/> FullName: The user's real name.
<br/>
<br/> JobView: Selects jobs that are displayed when the user creates
<br/> a changelist. These jobs can be closed automatically
<br/> when the user submits the changelist. For a description
<br/> of jobview syntax, see 'p4 help jobview'
<br/>
<br/> Reviews: The subscription list for change review. There is no
<br/> limit on the number of lines that this field can contain.
<br/> You can include the following wildcards:
<br/>
<br/> ... matches any characters including /
<br/> * matches any character except /
<br/>
<br/> Password: The user's password. See 'p4 help passwd'.
<br/>
<br/> Type: Must be 'service', operator, or 'standard'. Default is
<br/> 'standard'. Once set, the user type cannot be changed.
<br/>
<br/> AuthMethod: Must be 'perforce' or 'ldap'. Default is 'perforce'
<br/> Unless overridden by the 'auth.default.method'
<br/> configurable, see 'p4 help configurables'. AuthMethod
<br/> can only be changed when the -f flag has been provided.
<br/>
<br/> The -d flag deletes the specified user (unless the user has files
<br/> open).
<br/>
<br/> The -o flag writes the user specification to the standard output.
<br/> The user's editor is not invoked.
<br/>
<br/> The -i flag reads a user specification from the standard input.
<br/> The user's editor is not invoked.
<br/>
<br/> The -f flag forces the creation, update or deletion of the specified
<br/> user, and enables you to change the Last Modified date. By default,
<br/> users can only delete or modify their own user specifications. The
<br/> -f flag requires 'super' access, which is granted by 'p4 protect'.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Options.#ctor(Perforce.P4.UsersCmdFlags,System.Int32)">
<summary>
Users command options.
</summary>
<param name="flags"></param>
<param name="maxItems"></param>
<returns></returns>
<remarks>
<br/><b>p4 help users</b>
<br/>
<br/> users -- List Perforce users
<br/>
<br/> p4 users [-l -a -r -c] [-m max] [user ...]
<br/>
<br/> Lists all Perforce users or users that match the 'user' argument.
<br/> The report includes the last time that each user accessed the system.
<br/>
<br/> The -m max flag limits output to the first 'max' number of users.
<br/>
<br/> The -a flag includes service and operator users in the output.
<br/>
<br/> The -l flag includes additional information in the output. The -l
<br/> flag requires 'super' access, which is granted by 'p4 protect'.
<br/>
<br/> The -r and -c flags are only allowed on replica servers. When
<br/> -r is given only users who have used a replica are reported and
<br/> when -c is given only the user information from the central server
<br/> is reported. Otherwise on a replica server, the user list will
<br/> be slightly different from the master server as the user access times
<br/> will reflect replica usage or master usage whichever is newer.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Options.#ctor(Perforce.P4.ClientCmdFlags)">
<summary>
Client command options.
</summary>
<param name="flags"></param>
<returns></returns>
<remarks>
<br/><b>p4 help client</b>
<br/>
<br/> client -- Create or edit a client workspace specification and its view
<br/> workspace -- Synonym for 'client'
<br/>
<br/> p4 client [-f] [-t template] [name]
<br/> p4 client -d [-f [-Fs]] name
<br/> p4 client -o [-t template] [name]
<br/> p4 client -S stream [[-c change] -o] [name]
<br/> p4 client -s [-f] -S stream [name]
<br/> p4 client -s [-f] -t template [name]
<br/> p4 client -i [-f]
<br/>
<br/> Creates a new client specification ('spec') or edits an existing
<br/> spec. A client spec is a named mapping of depot files to workspace
<br/> files.
<br/>
<br/> The 'p4 client' command puts the client spec into a temporary file
<br/> and invokes the editor configured by the environment variable
<br/> $P4EDITOR. For new workspaces, the client name defaults to the
<br/> $P4CLIENT environment variable, if set, or to the current host name.
<br/> Saving the file creates or modifies the client spec.
<br/>
<br/> The client spec contains the following fields:
<br/>
<br/> Client: The client name.
<br/>
<br/> Host: If set, restricts access to the named host.
<br/> If unset, access is allowed from any host.
<br/>
<br/> Owner: The user who created this client.
<br/>
<br/> Update: The date that this spec was last modified.
<br/>
<br/> Access: The date that this client was last used in any way.
<br/>
<br/> Description: A short description of the workspace.
<br/>
<br/> Root: The root directory of the workspace (specified in local
<br/> file system syntax), under which all versioned files
<br/> will be placed. If you change this setting, you must
<br/> physically relocate any files that currently reside
<br/> there. On Windows client machines, you can specify the
<br/> root as "null" to enable you to map files to multiple
<br/> drives.
<br/>
<br/> AltRoots: Up to two optional alternate client workspace roots.
<br/> The first of the main and alternate roots to match the
<br/> client program's current working directory is used. If
<br/> none match, the main root is used. 'p4 info' displays
<br/> the root that is being used.
<br/>
<br/> Options: Flags to configure the client behavior. Defaults
<br/> are marked with *.
<br/>
<br/> allwrite Leaves all files writable on the client;
<br/> noallwrite * by default, only files opened by 'p4 edit'
<br/> are writable. If set, files might be clobbered
<br/> as a result of ignoring the clobber option
<br/> (see below).
<br/>
<br/> clobber Permits 'p4 sync' to overwrite writable
<br/> noclobber * files on the client. noclobber is ignored if
<br/> allwrite is set.
<br/>
<br/> compress Compresses data sent between the client
<br/> nocompress * and server to speed up slow connections.
<br/>
<br/> locked Allows only the client owner to use or change
<br/> unlocked * the client spec. Prevents the client spec from
<br/> being deleted or unloaded.
<br/>
<br/> modtime Causes 'p4 sync' and 'p4 submit' to preserve
<br/> nomodtime * file modification time, as with files with the
<br/> +m type modifier. (See 'p4 help filetypes'.)
<br/> With nomodtime, file timestamps are updated by
<br/> sync and submit operations.
<br/>
<br/> rmdir Makes 'p4 sync' attempt to delete a workspace
<br/> normdir * directory when all files in it are removed.
<br/>
<br/> SubmitOptions: Flags to change submit behavior.
<br/>
<br/> submitunchanged All open files are submitted (default).
<br/>
<br/> revertunchanged Files that have content, type, or resolved
<br/> changes are submitted. Unchanged files are
<br/> reverted.
<br/>
<br/> leaveunchanged Files that have content, type, or resolved
<br/> changes are submitted. Unchanged files are
<br/> moved to the default changelist.
<br/>
<br/> +reopen Can be appended to the submit option flag
<br/> to cause submitted files to be reopened in
<br/> the default changelist.
<br/> Example: submitunchanged+reopen
<br/>
<br/> LineEnd: Set line-ending character(s) for client text files.
<br/>
<br/> local mode that is native to the client (default).
<br/> unix linefeed: UNIX style.
<br/> mac carriage return: Macintosh style.
<br/> win carriage return-linefeed: Windows style.
<br/> share hybrid: writes UNIX style but reads UNIX,
<br/> Mac or Windows style.
<br/>
<br/> View: Maps files in the depot to files in your client
<br/> workspace. Defines the files that you want in your
<br/> client workspace and specifies where you want them
<br/> to reside. The default view maps all depot files
<br/> onto the client. See 'p4 help views' for view syntax.
<br/> A new view takes effect on the next 'p4 sync'.
<br/>
<br/> ChangeView: Restricts depot paths to a particular point in time.
<br/> Example: //depot/path/...@1000
<br/> Revisions submitted to the path after the specified
<br/> changelist will not be visible. Files matching a
<br/> ChangeView path may not be submitted.
<br/>
<br/> Stream: The stream to which this client's view will be dedicated.
<br/> (Files in stream paths can be submitted only by dedicated
<br/> stream clients.) When this optional field is set, the
<br/> View field will be automatically replaced by a stream
<br/> view as the client spec is saved.
<br/>
<br/> StreamAtChange:
<br/> Stream meta-data (for view creation) is versioned.
<br/> When StreamAtChange is set, the stream hierarchy is
<br/> constructed back-in-time to reproduce the view that was
<br/> available to clients in the past. With this field set
<br/> changes cannot be be submitted from the client.
<br/> StreamAtChange is optional; Stream must be set as well.
<br/>
<br/> ServerID: If set, restricts usage to the named server.
<br/> If unset, usage is allowed on the master server and on
<br/> any replicas of the master other than Edge Servers.
<br/>
<br/> Note: changing the client root does not actually move the client
<br/> files; you must relocate them manually. Similarly, changing
<br/> the 'LineEnd' option does not actually update the client files;
<br/> you can refresh them with 'p4 sync -f'.
<br/>
<br/> The -d flag deletes the specified spec, as long as the client
<br/> workspace has no opened files or pending changes. (See 'p4 help
<br/> opened'.) The -f flag forces the delete. The -Fs option used with -f
<br/> forces client deletion even when the user has shelved changes. In
<br/> this case, the shelved changes are left intact.
<br/>
<br/> The -o flag writes the named client spec to the standard output.
<br/> The user's editor is not invoked.
<br/>
<br/> The -i flag reads a client spec from the standard input. The
<br/> user's editor is not invoked.
<br/>
<br/> The -t template flag, where 'template' is the name of another client
<br/> spec, causes the View and Options fields to be replaced by those of
<br/> the template.
<br/>
<br/> The -f flag can force the updating of locked clients; normally
<br/> locked clients can only be modified by their owner. -f also allows
<br/> the last modified date to be set. The -f flag requires 'admin'
<br/> access granted by 'p4 protect'.
<br/>
<br/> The -s flag is used to switch an existing client spec's view without
<br/> invoking the editor. It can be used with -S to switch to a stream
<br/> view, or with -t to switch to a view defined in another client spec.
<br/> Switching views is not allowed in a client that has opened files.
<br/> The -f flag can be used with -s to force switching with opened files.
<br/> View switching has no effect on files in a client workspace until
<br/> 'p4 sync' is run.
<br/>
<br/> Without -s, the '-S stream' flag can be used to create a new client
<br/> spec dedicated to a stream. If the client spec already exists, and
<br/> -S is used without -s, an error occurs when the client is bound to
<br/> a different, or no stream. Using -S sets the new client's
<br/> Stream field. The special syntax '-S //a/stream@changelist' can
<br/> be used to set both Stream and StreamAtChange at the same time.
<br/>
<br/> The '-S stream' flag can be used with '-o -c change' to inspect an
<br/> old stream client view. It yields the client spec that would have
<br/> been created for the stream at the moment the change was recorded.
<br/>
<br/> A server of type 'build-server' (see 'p4 help server') is a replica
<br/> which supports build farm integration, and the 'p4 client' command
<br/> may be used to create or edit client workspaces on a build-server.
<br/> Such workspaces may issue the 'p4 sync' command, in addition to any
<br/> read-only command supported by the replica. For more information, run
<br/> 'p4 help buildserver'.
<br/>
<br/> When creating or editing a client workspace for a build-server,
<br/> the client specified by the optional 'name' argument, as well as the
<br/> client specified by the $P4CLIENT environment variable or via the
<br/> global '-c client' argument must not exist, or must be restricted
<br/> to this server; this command may not be used to create or edit a
<br/> workspace that is not restricted to this build-server.
<br/>
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Options.#ctor(Perforce.P4.ClientCmdFlags,System.String,System.String,System.Int32)">
<summary>
Client command options.
</summary>
<param name="flags"></param>
<param name="template"></param>
<param name="stream"></param>
<param name="change"></param>
<returns></returns>
<remarks>
<br/><b>p4 help client</b>
<br/>
<br/> client -- Create or edit a client workspace specification and its view
<br/> workspace -- Synonym for 'client'
<br/>
<br/> p4 client [-f] [-t template] [name]
<br/> p4 client -d [-f [-Fs]] name
<br/> p4 client -o [-t template] [name]
<br/> p4 client -S stream [[-c change] -o] [name]
<br/> p4 client -s [-f] -S stream [name]
<br/> p4 client -s [-f] -t template [name]
<br/> p4 client -i [-f]
<br/>
<br/> Creates a new client specification ('spec') or edits an existing
<br/> spec. A client spec is a named mapping of depot files to workspace
<br/> files.
<br/>
<br/> The 'p4 client' command puts the client spec into a temporary file
<br/> and invokes the editor configured by the environment variable
<br/> $P4EDITOR. For new workspaces, the client name defaults to the
<br/> $P4CLIENT environment variable, if set, or to the current host name.
<br/> Saving the file creates or modifies the client spec.
<br/>
<br/> The client spec contains the following fields:
<br/>
<br/> Client: The client name.
<br/>
<br/> Host: If set, restricts access to the named host.
<br/> If unset, access is allowed from any host.
<br/>
<br/> Owner: The user who created this client.
<br/>
<br/> Update: The date that this spec was last modified.
<br/>
<br/> Access: The date that this client was last used in any way.
<br/>
<br/> Description: A short description of the workspace.
<br/>
<br/> Root: The root directory of the workspace (specified in local
<br/> file system syntax), under which all versioned files
<br/> will be placed. If you change this setting, you must
<br/> physically relocate any files that currently reside
<br/> there. On Windows client machines, you can specify the
<br/> root as "null" to enable you to map files to multiple
<br/> drives.
<br/>
<br/> AltRoots: Up to two optional alternate client workspace roots.
<br/> The first of the main and alternate roots to match the
<br/> client program's current working directory is used. If
<br/> none match, the main root is used. 'p4 info' displays
<br/> the root that is being used.
<br/>
<br/> Options: Flags to configure the client behavior. Defaults
<br/> are marked with *.
<br/>
<br/> allwrite Leaves all files writable on the client;
<br/> noallwrite * by default, only files opened by 'p4 edit'
<br/> are writable. If set, files might be clobbered
<br/> as a result of ignoring the clobber option
<br/> (see below).
<br/>
<br/> clobber Permits 'p4 sync' to overwrite writable
<br/> noclobber * files on the client. noclobber is ignored if
<br/> allwrite is set.
<br/>
<br/> compress Compresses data sent between the client
<br/> nocompress * and server to speed up slow connections.
<br/>
<br/> locked Allows only the client owner to use or change
<br/> unlocked * the client spec. Prevents the client spec from
<br/> being deleted or unloaded.
<br/>
<br/> modtime Causes 'p4 sync' and 'p4 submit' to preserve
<br/> nomodtime * file modification time, as with files with the
<br/> +m type modifier. (See 'p4 help filetypes'.)
<br/> With nomodtime, file timestamps are updated by
<br/> sync and submit operations.
<br/>
<br/> rmdir Makes 'p4 sync' attempt to delete a workspace
<br/> normdir * directory when all files in it are removed.
<br/>
<br/> SubmitOptions: Flags to change submit behavior.
<br/>
<br/> submitunchanged All open files are submitted (default).
<br/>
<br/> revertunchanged Files that have content, type, or resolved
<br/> changes are submitted. Unchanged files are
<br/> reverted.
<br/>
<br/> leaveunchanged Files that have content, type, or resolved
<br/> changes are submitted. Unchanged files are
<br/> moved to the default changelist.
<br/>
<br/> +reopen Can be appended to the submit option flag
<br/> to cause submitted files to be reopened in
<br/> the default changelist.
<br/> Example: submitunchanged+reopen
<br/>
<br/> LineEnd: Set line-ending character(s) for client text files.
<br/>
<br/> local mode that is native to the client (default).
<br/> unix linefeed: UNIX style.
<br/> mac carriage return: Macintosh style.
<br/> win carriage return-linefeed: Windows style.
<br/> share hybrid: writes UNIX style but reads UNIX,
<br/> Mac or Windows style.
<br/>
<br/> View: Maps files in the depot to files in your client
<br/> workspace. Defines the files that you want in your
<br/> client workspace and specifies where you want them
<br/> to reside. The default view maps all depot files
<br/> onto the client. See 'p4 help views' for view syntax.
<br/> A new view takes effect on the next 'p4 sync'.
<br/>
<br/> ChangeView: Restricts depot paths to a particular point in time.
<br/> Example: //depot/path/...@1000
<br/> Revisions submitted to the path after the specified
<br/> changelist will not be visible. Files matching a
<br/> ChangeView path may not be submitted.
<br/>
<br/> Stream: The stream to which this client's view will be dedicated.
<br/> (Files in stream paths can be submitted only by dedicated
<br/> stream clients.) When this optional field is set, the
<br/> View field will be automatically replaced by a stream
<br/> view as the client spec is saved.
<br/>
<br/> StreamAtChange:
<br/> Stream meta-data (for view creation) is versioned.
<br/> When StreamAtChange is set, the stream hierarchy is
<br/> constructed back-in-time to reproduce the view that was
<br/> available to clients in the past. With this field set
<br/> changes cannot be be submitted from the client.
<br/> StreamAtChange is optional; Stream must be set as well.
<br/>
<br/> ServerID: If set, restricts usage to the named server.
<br/> If unset, usage is allowed on the master server and on
<br/> any replicas of the master other than Edge Servers.
<br/>
<br/> Note: changing the client root does not actually move the client
<br/> files; you must relocate them manually. Similarly, changing
<br/> the 'LineEnd' option does not actually update the client files;
<br/> you can refresh them with 'p4 sync -f'.
<br/>
<br/> The -d flag deletes the specified spec, as long as the client
<br/> workspace has no opened files or pending changes. (See 'p4 help
<br/> opened'.) The -f flag forces the delete. The -Fs option used with -f
<br/> forces client deletion even when the user has shelved changes. In
<br/> this case, the shelved changes are left intact.
<br/>
<br/> The -o flag writes the named client spec to the standard output.
<br/> The user's editor is not invoked.
<br/>
<br/> The -i flag reads a client spec from the standard input. The
<br/> user's editor is not invoked.
<br/>
<br/> The -t template flag, where 'template' is the name of another client
<br/> spec, causes the View and Options fields to be replaced by those of
<br/> the template.
<br/>
<br/> The -f flag can force the updating of locked clients; normally
<br/> locked clients can only be modified by their owner. -f also allows
<br/> the last modified date to be set. The -f flag requires 'admin'
<br/> access granted by 'p4 protect'.
<br/>
<br/> The -s flag is used to switch an existing client spec's view without
<br/> invoking the editor. It can be used with -S to switch to a stream
<br/> view, or with -t to switch to a view defined in another client spec.
<br/> Switching views is not allowed in a client that has opened files.
<br/> The -f flag can be used with -s to force switching with opened files.
<br/> View switching has no effect on files in a client workspace until
<br/> 'p4 sync' is run.
<br/>
<br/> Without -s, the '-S stream' flag can be used to create a new client
<br/> spec dedicated to a stream. If the client spec already exists, and
<br/> -S is used without -s, an error occurs when the client is bound to
<br/> a different, or no stream. Using -S sets the new client's
<br/> Stream field. The special syntax '-S //a/stream@changelist' can
<br/> be used to set both Stream and StreamAtChange at the same time.
<br/>
<br/> The '-S stream' flag can be used with '-o -c change' to inspect an
<br/> old stream client view. It yields the client spec that would have
<br/> been created for the stream at the moment the change was recorded.
<br/>
<br/> A server of type 'build-server' (see 'p4 help server') is a replica
<br/> which supports build farm integration, and the 'p4 client' command
<br/> may be used to create or edit client workspaces on a build-server.
<br/> Such workspaces may issue the 'p4 sync' command, in addition to any
<br/> read-only command supported by the replica. For more information, run
<br/> 'p4 help buildserver'.
<br/>
<br/> When creating or editing a client workspace for a build-server,
<br/> the client specified by the optional 'name' argument, as well as the
<br/> client specified by the $P4CLIENT environment variable or via the
<br/> global '-c client' argument must not exist, or must be restricted
<br/> to this server; this command may not be used to create or edit a
<br/> workspace that is not restricted to this build-server.
<br/>
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Options.#ctor(Perforce.P4.ClientsCmdFlags,System.String,System.String,System.Int32,System.String)">
<summary>
Clients command options.
</summary>
<param name="flags"></param>
<param name="userName"></param>
<param name="nameFilter"></param>
<param name="maxItems"></param>
<param name="stream"></param>
<returns></returns>
<remarks>
<br/><b>p4 help clients</b>
<br/>
<br/> clients -- Display list of clients
<br/> workspaces -- synonym for 'clients'
<br/>
<br/> p4 clients [-t] [-u user] [[-e|-E] nameFilter -m max] [-S stream]
<br/> [-a | -s serverID]
<br/> p4 clients -U
<br/>
<br/> Lists all client workspaces currently defined in the server.
<br/>
<br/> The -t flag displays the time as well as the date.
<br/>
<br/> The -u user flag lists client workspaces that are owned by the
<br/> specified user.
<br/>
<br/> The -e nameFilter flag lists workspaces with a name that matches
<br/> the nameFilter pattern, for example: -e 'svr-dev-rel*'. The -e flag
<br/> uses the server's normal case-sensitivity rules. The -E flag makes
<br/> the matching case-insensitive, even on a case-sensitive server.
<br/>
<br/> The -m max flag limits output to the specified number of workspaces.
<br/>
<br/> The -S stream flag limits output to the client workspaces dedicated
<br/> to the stream.
<br/>
<br/> The -U flag lists unloaded clients (see 'p4 help unload').
<br/>
<br/> The -a flag specifies that all clients should be displayed, not just
<br/> those that are bound to this server.
<br/>
<br/> The -s serverID flag specifies that only those clients bound to the
<br/> specified serverID should be displayed. On an Edge Server, the -s
<br/> flag defaults to the Edge Server's serverID.
<br/>
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Options.#ctor(Perforce.P4.ChangeCmdFlags)">
<summary>
Change command options.
</summary>
<param name="flags"></param>
<returns></returns>
<remarks>
<br/><b>p4 help change</b>
<br/>
<br/> change -- Create or edit a changelist description
<br/> changelist -- synonym for 'change'
<br/>
<br/> p4 change [-s] [-f | -u] [[-O] changelist#]
<br/> p4 change -d [-f -s -O] changelist#
<br/> p4 change -o [-s] [-f] [[-O] changelist#]
<br/> p4 change -i [-s] [-f | -u]
<br/> p4 change -t restricted | public [-U user] [-f | -u | -O] changelist#
<br/> p4 change -U user [-t restricted | public] [-f] changelist#
<br/>
<br/> 'p4 change' creates and edits changelists and their descriptions.
<br/> With no argument, 'p4 change' creates a new changelist. If a
<br/> changelist number is specified, 'p4 change' edits an existing
<br/> pending changelist. In both cases, the changelist specification
<br/> is placed into a form and the user's editor is invoked.
<br/>
<br/> The -d flag deletes a pending changelist, if it has no opened files
<br/> and no pending fixes associated with it. Use 'p4 opened -a' to
<br/> report on opened files and 'p4 reopen' to move them to another
<br/> changelist. Use 'p4 fixes -c changelist#' to report on pending
<br/> fixes and 'p4 fix -d -c changelist# jobs...' to delete pending
<br/> fixes. The changelist can be deleted only by the user and client
<br/> who created it, or by a user with 'admin' privilege using the -f
<br/> flag.
<br/>
<br/> The -o flag writes the changelist specification to the standard
<br/> output. The user's editor is not invoked.
<br/>
<br/> The -i flag reads a changelist specification from the standard
<br/> input. The user's editor is not invoked.
<br/>
<br/> The -f flag forces the update or deletion of other users' pending
<br/> changelists. -f can also force the deletion of submitted changelists
<br/> after they have been emptied of files using 'p4 obliterate'. By
<br/> default, submitted changelists cannot be changed. The -f flag can
<br/> also force display of the 'Description' field in a restricted
<br/> changelist. Finally the -f flag can force changing the 'User' of
<br/> an empty pending change via -U. The -f flag requires 'admin'
<br/> access granted by 'p4 protect'. The -f and -u flags are mutually
<br/> exclusive.
<br/>
<br/> The -u flag can force the update of a submitted change by the owner
<br/> of the change. Only the Jobs, Type, and Description fields can be
<br/> changed using the -u flag. The -f and -u flags cannot be used in
<br/> the same change command.
<br/>
<br/> The -s flag extends the list of jobs to include the fix status
<br/> for each job. On new changelists, the fix status begins as the
<br/> special status 'ignore', which, if left unchanged simply excludes
<br/> the job from those being fixed. Otherwise, the fix status, like
<br/> that applied with 'p4 fix -s', becomes the job's status when
<br/> the changelist is committed. Note that this option exists
<br/> to support integration with external defect trackers.
<br/>
<br/> The -O flag specifies that the changelist number is the original
<br/> number of a changelist which was renamed on submit.
<br/>
<br/> The -U flag changes the 'User' of an empty pending change to the
<br/> specified user. The user field can only be changed using this flag
<br/> by the user who created the change, or by a user with 'admin'
<br/> privilege using the -f flag. This option is useful for running
<br/> in a trigger or script.
<br/>
<br/> The -t flag changes the 'Type' of the change to 'restricted'
<br/> or 'public' without displaying the change form. This option is
<br/> useful for running in a trigger or script.
<br/>
<br/> The 'Type' field can be used to hide the change or its description
<br/> from users. Valid values for this field are 'public' (default), and
<br/> 'restricted'. A shelved or committed change that is 'restricted' is
<br/> accessible only to users who own the change or have 'list' permission
<br/> to at least one file in the change. A pending (not shelved)
<br/> restricted change is only accessible to its owner. Public changes
<br/> are accessible to all users. This setting affects the output of the
<br/> 'p4 change', 'p4 changes', and 'p4 describe' commands. Note that
<br/> the '-S' flag is required with 'p4 describe' for the command to
<br/> enforce shelved rather than pending restricted changelist rules.
<br/>
<br/> If a user is not permitted to have access to a restricted change,
<br/> The 'Description' text is replaced with a 'no permission' message
<br/> (see 'Type' field). Users with admin permission can override the
<br/> restriction using the -f flag.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Options.#ctor(Perforce.P4.ChangeCmdFlags,ChangeListType)">
<summary>
Change command options.
</summary>
<param name="flags"></param>
<param name="newType"></param>
<returns></returns>
<remarks>
<br/><b>p4 help change</b>
<br/>
<br/> change -- Create or edit a changelist description
<br/> changelist -- synonym for 'change'
<br/>
<br/> p4 change [-s] [-f | -u] [[-O] changelist#]
<br/> p4 change -d [-f -s -O] changelist#
<br/> p4 change -o [-s] [-f] [[-O] changelist#]
<br/> p4 change -i [-s] [-f | -u]
<br/> p4 change -t restricted | public [-U user] [-f | -u | -O] changelist#
<br/> p4 change -U user [-t restricted | public] [-f] changelist#
<br/>
<br/> 'p4 change' creates and edits changelists and their descriptions.
<br/> With no argument, 'p4 change' creates a new changelist. If a
<br/> changelist number is specified, 'p4 change' edits an existing
<br/> pending changelist. In both cases, the changelist specification
<br/> is placed into a form and the user's editor is invoked.
<br/>
<br/> The -d flag deletes a pending changelist, if it has no opened files
<br/> and no pending fixes associated with it. Use 'p4 opened -a' to
<br/> report on opened files and 'p4 reopen' to move them to another
<br/> changelist. Use 'p4 fixes -c changelist#' to report on pending
<br/> fixes and 'p4 fix -d -c changelist# jobs...' to delete pending
<br/> fixes. The changelist can be deleted only by the user and client
<br/> who created it, or by a user with 'admin' privilege using the -f
<br/> flag.
<br/>
<br/> The -o flag writes the changelist specification to the standard
<br/> output. The user's editor is not invoked.
<br/>
<br/> The -i flag reads a changelist specification from the standard
<br/> input. The user's editor is not invoked.
<br/>
<br/> The -f flag forces the update or deletion of other users' pending
<br/> changelists. -f can also force the deletion of submitted changelists
<br/> after they have been emptied of files using 'p4 obliterate'. By
<br/> default, submitted changelists cannot be changed. The -f flag can
<br/> also force display of the 'Description' field in a restricted
<br/> changelist. Finally the -f flag can force changing the 'User' of
<br/> an empty pending change via -U. The -f flag requires 'admin'
<br/> access granted by 'p4 protect'. The -f and -u flags are mutually
<br/> exclusive.
<br/>
<br/> The -u flag can force the update of a submitted change by the owner
<br/> of the change. Only the Jobs, Type, and Description fields can be
<br/> changed using the -u flag. The -f and -u flags cannot be used in
<br/> the same change command.
<br/>
<br/> The -s flag extends the list of jobs to include the fix status
<br/> for each job. On new changelists, the fix status begins as the
<br/> special status 'ignore', which, if left unchanged simply excludes
<br/> the job from those being fixed. Otherwise, the fix status, like
<br/> that applied with 'p4 fix -s', becomes the job's status when
<br/> the changelist is committed. Note that this option exists
<br/> to support integration with external defect trackers.
<br/>
<br/> The -O flag specifies that the changelist number is the original
<br/> number of a changelist which was renamed on submit.
<br/>
<br/> The -U flag changes the 'User' of an empty pending change to the
<br/> specified user. The user field can only be changed using this flag
<br/> by the user who created the change, or by a user with 'admin'
<br/> privilege using the -f flag. This option is useful for running
<br/> in a trigger or script.
<br/>
<br/> The -t flag changes the 'Type' of the change to 'restricted'
<br/> or 'public' without displaying the change form. This option is
<br/> useful for running in a trigger or script.
<br/>
<br/> The 'Type' field can be used to hide the change or its description
<br/> from users. Valid values for this field are 'public' (default), and
<br/> 'restricted'. A shelved or committed change that is 'restricted' is
<br/> accessible only to users who own the change or have 'list' permission
<br/> to at least one file in the change. A pending (not shelved)
<br/> restricted change is only accessible to its owner. Public changes
<br/> are accessible to all users. This setting affects the output of the
<br/> 'p4 change', 'p4 changes', and 'p4 describe' commands. Note that
<br/> the '-S' flag is required with 'p4 describe' for the command to
<br/> enforce shelved rather than pending restricted changelist rules.
<br/>
<br/> If a user is not permitted to have access to a restricted change,
<br/> The 'Description' text is replaced with a 'no permission' message
<br/> (see 'Type' field). Users with admin permission can override the
<br/> restriction using the -f flag.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Options.#ctor(Perforce.P4.ChangesCmdFlags,System.String,System.Int32,Perforce.P4.ChangeListStatus,System.String)">
<summary>
Changes command options.
</summary>
<param name="flags"></param>
<param name="clientName"></param>
<param name="maxItems"></param>
<param name="status"></param>
<param name="userName"></param>
<returns></returns>
<remarks>
<br/><b>p4 help changes</b>
<br/>
<br/> changes -- Display list of pending and submitted changelists
<br/> changelists -- synonym for 'changes'
<br/>
<br/> p4 changes [options] [file[revRange] ...]
<br/>
<br/> options: -i -t -l -L -f -c client -m max -s status -u user
<br/>
<br/> Returns a list of all pending and submitted changelists currently
<br/> stored in the server.
<br/>
<br/> If files are specified, 'p4 changes' lists only changelists that
<br/> affect those files. If the file specification includes a revision
<br/> range, 'p4 changes' lists only submitted changelists that affect
<br/> the specified revisions. See 'p4 help revisions' for details.
<br/>
<br/> If files are not specified, 'p4 changes' limits its report
<br/> according to each change's type ('public' or 'restricted').
<br/> If a submitted or shelved change is restricted, the change is
<br/> not reported unless the user owns the change or has list
<br/> permission for at least one file in the change. Only the owner
<br/> of a restricted and pending (not shelved) change is permitted
<br/> to see it.
<br/>
<br/> The -i flag also includes any changelists integrated into the
<br/> specified files.
<br/>
<br/> The -t flag displays the time as well as the date.
<br/>
<br/> The -l flag displays the full text of the changelist
<br/> descriptions.
<br/>
<br/> The -L flag displays the changelist descriptions, truncated to 250
<br/> characters if longer.
<br/>
<br/> The -f flag enables admin users to view restricted changes.
<br/>
<br/> The -c client flag displays only submitted by the specified client.
<br/>
<br/> The -m max flag limits changes to the 'max' most recent.
<br/>
<br/> The -s status flag limits the output to changelists with the specified
<br/> status. Specify '-s pending', '-s shelved', or '-s submitted'.
<br/>
<br/> The -u user flag displays only changes owned by the specified user.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Options.#ctor(Perforce.P4.GroupCmdFlags)">
<summary>
Group command options.
</summary>
<param name="flags"></param>
<returns></returns>
<remarks>
<br/><b>p4 help group</b>
<br/>
<br/> group -- Change members of user group
<br/>
<br/> p4 group [-a|-A] name
<br/> p4 group -d [-a] name
<br/> p4 group -o name
<br/> p4 group -i [-a|-A]
<br/>
<br/> Create a group or modify the membership of an existing group.
<br/> A group can contain users and other groups. The group specification
<br/> is put into a temporary file and the editor (configured by the
<br/> environment variable $P4EDITOR) is invoked.
<br/>
<br/> A group exists when it has any users or other groups in it, and
<br/> ceases to exist if all users and groups in it are removed.
<br/>
<br/> Each group has MaxResults, MaxScanRows, and MaxLockTime fields,
<br/> which limit the resources committed to operations performed by
<br/> members of the group. For these fields, 'unlimited' or 'unset'
<br/> means no limit for that group. An individual user's limit is the
<br/> highest of any group with a limit to which he belongs, unlimited if
<br/> any of his groups has 'unlimited' for that field, or unlimited
<br/> if he belongs to no group with a limit. See 'p4 help maxresults'
<br/> for more information on MaxResults, MaxScanRows and MaxLockTime.
<br/>
<br/> Each group also has a Timeout field, which specifies how long (in
<br/> seconds) a 'p4 login' ticket remains valid. A value of 'unset' or
<br/> 'unlimited' is equivalent to no timeout. An individual's timeout is
<br/> the highest of any group with a limit to which he belongs, unlimited
<br/> if any of his groups has 'unlimited' for the timeout value, or
<br/> unlimited if he belongs to no group with a limit. See 'p4 help login'
<br/> for more information.
<br/>
<br/> Each group has a PasswordTimeout field, which determines how long a
<br/> password remains valid for members of the group.
<br/>
<br/> A group may be synchronized with an LDAP group by setting the three
<br/> fields: LdapConfig, LdapSearchQuery and LdapUserAttribute. This takes
<br/> the LDAP configuration (see 'p4 ldap') specified by LdapConfig and uses
<br/> it to execute the query stored by LdapSearchQuery. The LDAP attribute
<br/> specified by LdapUserAttribute is taken to be user's username and is
<br/> added to the group's user list. At least one group owner must be set if
<br/> these LDAP fields are used. If the LDAP server requires login for
<br/> read-only queries, then the LDAP configuration must contain valid bind
<br/> credentials in the LDAP spec's SearchBindDN and SearchPasswd fields
<br/>
<br/> The -d flag deletes a group.
<br/>
<br/> The -o flag writes the group specification to standard output. The
<br/> user's editor is not invoked.
<br/>
<br/> The -i flag reads a group specification from standard input. The
<br/> user's editor is not invoked. The new group specification replaces
<br/> the previous one.
<br/>
<br/> The -a flag enables a user without 'super' access to modify the group
<br/> if that user is an 'owner' of that group. Group owners are specified
<br/> in the 'Owners' field of the group spec.
<br/>
<br/> The -A flag enables a user with 'admin' access to add a new group.
<br/> Existing groups may not be modified when this flag is used.
<br/>
<br/> All commands that require access granted by 'p4 protect' consider a
<br/> user's groups when calculating access levels.
<br/>
<br/> 'p4 group' requires 'super' access granted by 'p4 protect' unless
<br/> invoked with the '-a' or '-A' flag by a qualified user.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Options.#ctor(Perforce.P4.GroupsCmdFlags,System.Int32)">
<summary>
Groups command options.
</summary>
<param name="flags"></param>
<param name="maxItems"></param>
<returns></returns>
<remarks>
<br/><b>p4 help groups</b>
<br/>
<br/> groups -- List groups (of users)
<br/>
<br/> p4 groups [-m max] [-v] [group]
<br/> p4 groups [-m max] [-i [-v]] user | group
<br/> p4 groups [-m max] [-g | -u | -o] name
<br/>
<br/> The first form lists all user groups defined in the server, or just
<br/> the specified group.
<br/>
<br/> The second form displays subgroup relationships. If a user argument is
<br/> specified, only groups containing that user are displayed. If a group
<br/> argument is specified, only groups containing the group are displayed.
<br/>
<br/> The third form is useful when there are groups and users with the
<br/> same name, or when requesting all groups owned by a certain user.
<br/>
<br/> The -i flag also displays groups that the user or group belongs to
<br/> indirectly by means of membership in subgroups.
<br/>
<br/> The -m max flag limits output to the specified number of groups.
<br/>
<br/> The -v flag displays the MaxResults, MaxScanRows, MaxLockTime, and
<br/> Timeout values for each group that is displayed.
<br/>
<br/> The -g flag indicates that the 'name' argument is a group.
<br/>
<br/> The -u flag indicates that the 'name' argument is a user.
<br/>
<br/> The -o flag indicates that the 'name' argument is an owner.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Options.#ctor(Perforce.P4.JobCmdFlags)">
<summary>
Options for job command.
</summary>
<param name="flags"></param>
<returns></returns>
<remarks>
<br/><b>p4 help job</b>
<br/>
<br/> job -- Create or edit a job (defect) specification
<br/>
<br/> p4 job [-f] [jobName]
<br/> p4 job -d jobName
<br/> p4 job -o [jobName]
<br/> p4 job -i [-f]
<br/>
<br/> The 'p4 job' command creates and edits job specifications using an
<br/> ASCII form. A job is a defect, enhancement, or other unit of
<br/> intended work.The 'p4 fix' command associates changelists with jobs.
<br/>
<br/> With no arguments, 'p4 job' creates an empty job specification
<br/> and invokes the user's editor. When the specification is saved,
<br/> a job name of the form jobNNNNNN is assigned. If the jobName
<br/> parameter is specified on the command line, the job is created or
<br/> opened for editing.
<br/>
<br/> As jobs are entered or updated, all fields are indexed for searching
<br/> Text fields are broken into individual alphanumeric words (punctuation
<br/> and whitespace are ignored) and each word is case-folded and entered
<br/> into the word index. Date fields are converted to an internal
<br/> representation (seconds since 1970/01/01 00:00:00) and entered
<br/> into the date index.
<br/>
<br/> The fields that compose a job are defined by the 'p4 jobspec' command.
<br/> Perforce provides a default job specification that you can edit.
<br/>
<br/> The -d flag deletes the specified job. You cannot delete a job if
<br/> it has pending or submitted fixes associated with it.
<br/>
<br/> The -o flag writes the job specification to the standard output.
<br/> The user's editor is not invoked.
<br/>
<br/> The -i flag reads a job specification from the standard input. The
<br/> user's editor is not invoked.
<br/>
<br/> The -f flag enables you set fields that are read-only by default.
<br/> The -f flag requires 'admin' access, which is granted using the
<br/> 'p4 protect' command.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Options.#ctor(Perforce.P4.JobsCmdFlags,System.String,System.Int32)">
<summary>
Jobs command options.
</summary>
<param name="flags"></param>
<param name="jobView"></param>
<param name="maxItems"></param>
<returns></returns>
<remarks>
<br/><b>p4 help jobs</b>
<br/>
<br/> jobs -- Display list of jobs
<br/>
<br/> p4 jobs [-e jobview -i -l -m max -r] [file[revRange] ...]
<br/> p4 jobs -R
<br/>
<br/> Lists jobs in the server. If a file specification is included, fixes
<br/> for submitted changelists affecting the specified files are listed.
<br/> The file specification can include wildcards and a revision range.
<br/> See 'p4 help revisions' for details about specifying revisions.
<br/>
<br/> The -e flag lists jobs matching the expression specified in the
<br/> jobview parameter. For a description of jobview syntax, see 'p4 help
<br/> jobview'.
<br/>
<br/> The -i flag includes any fixes made by changelists integrated into
<br/> the specified files.
<br/>
<br/> The -l flag produces long output with the full text of the job
<br/> descriptions.
<br/>
<br/> The -m max flag limits the output to the first 'max' jobs, ordered
<br/> by their job name.
<br/>
<br/> The -r flag sorts the jobs in reverse order (by job name).
<br/>
<br/> The -R flag rebuilds the jobs table and reindexes each job, which
<br/> is necessary after upgrading to 98.2. 'p4 jobs -R' requires that the
<br/> user be an operator or have 'super' access granted by 'p4 protect'.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Options.#ctor(Perforce.P4.FilesCmdFlags,System.Int32)">
<summary>
Options for the files command.
</summary>
<param name="flags"></param>
<param name="maxItems"></param>
<returns></returns>
<remarks>
p4 help Files
</remarks>
</member>
<member name="M:Perforce.P4.Options.#ctor(Perforce.P4.FileLogCmdFlags,System.Int32,System.Int32)">
<summary>
Options for the filelog command.
</summary>
</member>
<member name="M:Perforce.P4.Options.#ctor(Perforce.P4.LoginCmdFlags,System.String)">
<summary>
Options for the login command.
</summary>
</member>
<member name="M:Perforce.P4.Options.#ctor(Perforce.P4.LogoutCmdFlags,System.String)">
<summary>
Options for the logout command.
</summary>
</member>
<member name="M:Perforce.P4.Options.#ctor(Perforce.P4.TagFilesCmdFlags,System.String)">
<summary>
Options for the tag command.
</summary>
</member>
<member name="M:Perforce.P4.Options.#ctor(Perforce.P4.GetOpenedFilesCmdFlags,System.String,System.String,System.String,System.Int32)">
<summary>
Options for GetOpenedFiles
</summary>
<param name="flags"></param>
<param name="changelist"></param>
<param name="client"></param>
<param name="user"></param>
<param name="maxItems"></param>
<remarks>
<br/><b>p4 help opened</b>
<br/>
<br/> opened -- List open files and display file status
<br/>
<br/> p4 opened [-a -c changelist# -C client -u user -m max -s] [file ...]
<br/> p4 opened [-a -x -m max ] [file ...]
<br/>
<br/> Lists files currently opened in pending changelists, or, for
<br/> specified files, show whether they are currently opened or locked.
<br/> If the file specification is omitted, all files open in the current
<br/> client workspace are listed.
<br/>
<br/> Files in shelved changelists are not displayed by this command. To
<br/> display shelved changelists, see 'p4 changes -s shelved'; to display
<br/> the files in those shelved changelists, see 'p4 describe -s -S'.
<br/>
<br/> The -a flag lists opened files in all clients. By default, only
<br/> files opened by the current client are listed.
<br/>
<br/> The -c changelist# flag lists files opened in the specified
<br/> changelist#.
<br/>
<br/> The -C client flag lists files open in the specified client workspace.
<br/>
<br/> The -u user flag lists files opened by the specified user.
<br/>
<br/> The -m max flag limits output to the first 'max' number of files.
<br/>
<br/> The -s option produces 'short' and optimized output when used with
<br/> the -a (all clients) option. For large repositories '-a' can take
<br/> a long time when compared to '-as'.
<br/>
<br/> The -x option lists files that are opened 'exclusive'. This option
<br/> only applies to a distributed installation where global tracking of
<br/> these file types is necessary across servers. The -x option implies
<br/> the -a option.
<br/>
<br/>
</remarks>
</member>
<!-- Badly formed XML comment ignored for member "M:Perforce.P4.Options.#ctor(Perforce.P4.GetFileMetadataCmdFlags,System.String,System.String,System.Int32,System.String,System.String)" -->
<member name="M:Perforce.P4.Options.#ctor(Perforce.P4.GetFileContentsCmdFlags,System.String)">
<summary>
Command options for GetFileContentsCmd()
</summary>
<param name="flags"></param>
<param name="localFile"></param>
<remarks>
<br/><b>p4 help print</b>
<br/>
<br/> print -- Write a depot file to standard output
<br/>
<br/> p4 print [-a -A -k -o localFile -q -m max] file[revRange] ...
<br/> p4 print -U unloadfile ...
<br/>
<br/> Retrieve the contents of a depot file to the client's standard output.
<br/> The file is not synced. If file is specified using client syntax,
<br/> Perforce uses the client view to determine the corresponding depot
<br/> file.
<br/>
<br/> By default, the head revision is printed. If the file argument
<br/> includes a revision, the specified revision is printed. If the
<br/> file argument has a revision range, then only files selected by
<br/> that revision range are printed, and the highest revision in the
<br/> range is printed. For details about revision specifiers, see 'p4
<br/> help revisions'.
<br/>
<br/> The -a flag prints all revisions within the specified range, rather
<br/> than just the highest revision in the range.
<br/>
<br/> The -A flag prints files in archive depots.
<br/>
<br/> The -k flag suppresses keyword expansion.
<br/>
<br/> The -o localFile flag redirects the output to the specified file on
<br/> the client filesystem.
<br/>
<br/> The -q flag suppresses the initial line that displays the file name
<br/> and revision.
<br/>
<br/> The -m flag limits print to the first 'max' number of files.
<br/>
<br/> The -U option prints files in the unload depot (see 'p4 help unload'
<br/> for more information about the unload depot).
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Options.#ctor(Perforce.P4.DescribeChangelistCmdFlags,System.Int32,System.Int32)">
<summary>
Options for the Describe command
</summary>
<param name="flags"></param>
<param name="contextLines"></param>
<param name="unifiedLines"></param>
<remarks>
<br/><b>p4 help describe</b>
<br/>
<br/> describe -- Display a changelist description
<br/>
<br/> p4 describe [-d<flags> -m -s -S -f -O] changelist# ...
<br/>
<br/> Display a changelist description, including the changelist number,
<br/> user, client, date of submission, textual description, list of
<br/> affected files and diffs of files updated. Pending changelists
<br/> are indicated as 'pending' and file diffs are not displayed.
<br/>
<br/> For restricted changelists, 'no permission' is displayed if the user
<br/> is not permitted to view the change (see 'p4 help change'). If a
<br/> submitted change is restricted, the description is hidden unless
<br/> the user is the owner of the change or has list permission for
<br/> at least one file in the change. If a shelved change is restricted,
<br/> the description is hidden unless the user is the owner of the change,
<br/> or has list permission to at least one file in the change and has
<br/> used the -S flag to request the shelved change. To view restricted
<br/> pending (not shelved) changes, the user must be the owner of the
<br/> change.
<br/>
<br/> The -d<flags> passes one or more flags to the built-in diff routine
<br/> to modify the output: -dn (RCS), -dc[n] (context), -ds (summary),
<br/> -du[n] (unified), -db (ignore whitespace changes), -dw (ignore
<br/> whitespace), -dl (ignore line endings). The optional argument to
<br/> to -dc/-du specifies number of context lines.
<br/>
<br/> The -s flag omits the diffs of files that were updated.
<br/>
<br/> The -S flag lists files that are shelved for the specified changelist
<br/> and displays diffs of the files against their previous revision.
<br/> If the change is restricted, the description is displayed according
<br/> to the rules for shelved restricted changes described above.
<br/>
<br/> The -f flag forces display of the descriptions in a restricted
<br/> change. The -f flag requires 'admin' access, which is granted
<br/> using 'p4 protect'.
<br/>
<br/> The -O flag specifies that the changelist number is the original
<br/> number of a changelist which was renamed on submit.
<br/>
<br/> The -m flag limits files to the first 'max' number of files.
<br/>
<br/>
</remarks>
</member>
<member name="M:Perforce.P4.Options.#ctor(Perforce.P4.TrustCmdFlags)">
<summary>
Options for the trust command
</summary>
<param name="flags"></param>
<remarks>
<br/><b>p4 trust -h</b>
<br/>
<br/> trust -- Establish trust of an SSL connection
<br/>
<br/> p4 trust [ -l -y -n -d -f -r -i <fingerprint> ]
<br/>
<br/> Establish trust of an SSL connection. This client command manages
<br/> the p4 trust file. This file contains fingerprints of the keys
<br/> received on ssl connections. When an SSL connection is made, this
<br/> file is examined to determine if the SSL connection has been used
<br/> before and if the key is the same as a previously seen key for that
<br/> connection. Establishing trust with a connection prevents undetected
<br/> communication interception (man-in-the-middle) attacks.
<br/>
<br/> Most options are mutually exclusive. Only the -r and -f options
<br/> can be combined with the others.
<br/>
<br/> The -l flag lists existing known fingerprints.
<br/>
<br/> Without options, this command will make a connection to a server
<br/> and examine the key if present, if one cannot be found this command
<br/> will show a fingerprint and ask if this connection should be trusted.
<br/> If a fingerprint exists and does not match, an error that a possible
<br/> security problems exists will be displayed.
<br/>
<br/> The -y flag will cause prompts to be automatically accepted.
<br/>
<br/> The -n flag will cause prompts to be automatically refused.
<br/>
<br/> The -d flag will remove an existing trusted fingerprint of a connection.
<br/>
<br/> The -f flag will force the replacement of a mismatched fingerprint.
<br/>
<br/> The -i flag will allow a specific fingerprint to be installed.
<br/>
<br/> The -r flag specifies that a replacement fingerprint is to be
<br/> affected. Replacement fingerprints can be used in anticipation
<br/> of a server replacing its key. If a replacement fingerprint
<br/> exists for a connection and the primary fingerprint does not match
<br/> while the replacement fingerprint does, the replacement fingerprint
<br/> will replace the primary. This flag can be combined with -l, -i,
<br/> or -d.
</remarks>
</member>
<member name="M:Perforce.P4.Options.#ctor(Perforce.P4.InfoCmdFlags)">
<summary>
Options for the trust command
</summary>
<param name="flags"></param>
<remarks>
<br/><b>p4 help info</b>
<br/>
<br/> info -- Display client/server information
<br/>
<br/> p4 info [-s]
<br/>
<br/> Info lists information about the current client (user name,
<br/> client name, applicable client root, client current directory,
<br/> and the client IP address) and some server information (server
<br/> IP address, server root, date, uptime, version and license data).
<br/>
<br/> The -s option produces 'short' output that omits any information
<br/> that requires a database lookup such as the client root).
<br/>
<br/>
</remarks>
</member>
<member name="T:Perforce.P4.AddFilesCmdFlags">
<summary>
Flags for the add command.
</summary>
</member>
<member name="F:Perforce.P4.AddFilesCmdFlags.None">
<summary>
No flags.
</summary>
</member>
<member name="F:Perforce.P4.AddFilesCmdFlags.Downgrade">
<summary>
As a shortcut to reverting and re-adding, you can use the -d
flag to reopen currently-open files for add (downgrade) under
the following circumstances:
A file that is 'opened for edit' and is synced to the head
revision, and the head revision has been deleted (or moved).
A file that is 'opened for move/add' can be downgraded to add,
which is useful when the source of the move has been deleted
or moved. Typically, under these circumstances, your only
alternative is to revert. In this case, breaking the move
connection enables you to preserve any content changes in the
new file and safely revert the source file (of the move).
</summary>
</member>
<member name="F:Perforce.P4.AddFilesCmdFlags.KeepWildcards">
<summary>
To add files with filenames that contain wildcard characters, specify
the -f flag. Filenames that contain the special characters '@', '#',
'%' or '*' are reformatted to encode the characters using ASCII
hexadecimal representation.
</summary>
</member>
<member name="F:Perforce.P4.AddFilesCmdFlags.NoP4Ignore">
<summary>
The -I flag informs the client that it should not perform any ignore
checking configured by P4IGNORE.
</summary>
</member>
<member name="F:Perforce.P4.AddFilesCmdFlags.PreviewOnly">
<summary>
The -n flag, displays a preview of the specified add operation without
changing any files or metadata.
</summary>
</member>
<member name="T:Perforce.P4.AddFilesCmdOptions">
<summary>
Add command options
</summary>
</member>
<member name="M:Perforce.P4.AddFilesCmdOptions.#ctor(Perforce.P4.AddFilesCmdFlags,System.Int32,Perforce.P4.FileType)">
<summary>
Options for the Add command.
</summary>
<param name="flags">Flags for the command</param>
<param name="changeList">Optional changelist for the fies</param>
<param name="fileType">Optional file type for the files</param>
<returns></returns>
<remarks>
<br/><b>p4 help add</b>
<br/>
<br/> add -- Open a new file to add it to the depot
<br/>
<br/> p4 add [-c changelist#] [-d -f -I -n] [-t filetype] file ...
<br/>
<br/> Open a file for adding to the depot. If the file exists on the
<br/> client, it is read to determine if it is text or binary. If it does
<br/> not exist, it is assumed to be text. To be added, the file must not
<br/> already reside in the depot, or it must be deleted at the current
<br/> head revision. Files can be deleted and re-added.
<br/>
<br/> A 2012.1 client will ignore files that were to be added, if they
<br/> match an exclusion line specified in a P4IGNORE file.
<br/>
<br/> To associate the open files with a specific pending changelist, use
<br/> the -c flag; if you omit the -c flag, the open files are associated
<br/> with the default changelist. If file is already open, it is moved
<br/> into the specified pending changelist. You cannot reopen a file for
<br/> add unless it is already open for add.
<br/>
<br/> As a shortcut to reverting and re-adding, you can use the -d
<br/> flag to reopen currently-open files for add (downgrade) under
<br/> the following circumstances:
<br/>
<br/> A file that is 'opened for edit' and is synced to the head
<br/> revision, and the head revision has been deleted (or moved).
<br/>
<br/> A file that is 'opened for move/add' can be downgraded to add,
<br/> which is useful when the source of the move has been deleted
<br/> or moved. Typically, under these circumstances, your only
<br/> alternative is to revert. In this case, breaking the move
<br/> connection enables you to preserve any content changes in the
<br/> new file and safely revert the source file (of the move).
<br/>
<br/> To specify file type, use the -t flag. By default, 'p4 add'
<br/> determines file type using the name-to-type mapping table managed
<br/> by 'p4 typemap' and by examining the file's contents and execute
<br/> permission bit. If the file type specified by -t or configured in
<br/> the typemap table is a partial filetype, the resulting modifier is
<br/> applied to the file type that is determined by 'p4 add'. For more
<br/> details, see 'p4 help filetypes'.
<br/>
<br/> To add files with filenames that contain wildcard characters, specify
<br/> the -f flag. Filenames that contain the special characters '@', '#',
<br/> '%' or '*' are reformatted to encode the characters using ASCII
<br/> hexadecimal representation. After the files are added, you must
<br/> refer to them using the reformatted file name, because Perforce
<br/> does not recognize the local filesystem name.
<br/>
<br/> The -I flag informs the client that it should not perform any ignore
<br/> checking configured by P4IGNORE.
<br/>
<br/> The -n flag displays a preview of the specified add operation without
<br/> changing any files or metadata.
<br/>
<br/>
</remarks>
</member>
<member name="T:Perforce.P4.DeleteFilesCmdFlags">
<summary>
Flags for the delete command.
</summary>
</member>
<member name="F:Perforce.P4.DeleteFilesCmdFlags.None">
<summary>
No flags.
</summary>
</member>
<member name="F:Perforce.P4.DeleteFilesCmdFlags.PreviewOnly">
<summary>
The -n flag, displays a preview of the operation without changing any
files or metadata.
</summary>
</member>
<member name="F:Perforce.P4.DeleteFilesCmdFlags.DeleteUnsynced">
<summary>
The -v flag, enables you to delete files that are not synced to the
client workspace.
</summary>
</member>
<member name="F:Perforce.P4.DeleteFilesCmdFlags.ServerOnly">
<summary>
The -k flag performs the delete on the server without modifying
client files. Use with caution, as an incorrect delete can cause
discrepancies between the state of the client and the corresponding
server metadata.
</summary>
</member>
<member name="T:Perforce.P4.DeleteFilesCmdOptions">
<summary>
delete command options
</summary>
</member>
<member name="M:Perforce.P4.DeleteFilesCmdOptions.#ctor(Perforce.P4.DeleteFilesCmdFlags,System.Int32)">
<summary>
Options for the delete command.
</summary>
<param name="flags"></param>
<param name="changeList"></param>
<returns></returns>
<remarks>
<br/><b>p4 help delete</b>
<br/>
<br/> delete -- Open an existing file for deletion from the depot
<br/>
<br/> p4 delete [-c changelist#] [-n -v -k] file ...
<br/>
<br/> Opens a depot file for deletion.
<br/> If the file is synced in the client workspace, it is removed. If a
<br/> pending changelist number is specified using with the -c flag, the
<br/> file is opened for delete in that changelist. Otherwise, it is opened
<br/> in the default pending changelist.
<br/>
<br/> Files that are deleted generally do not appear on the have list.
<br/>
<br/> The -n flag displays a preview of the operation without changing any
<br/> files or metadata.
<br/>
<br/> The -k flag performs the delete on the server without modifying
<br/> client files. Use with caution, as an incorrect delete can cause
<br/> discrepancies between the state of the client and the corresponding
<br/> server metadata.
<br/>
<br/> The -v flag enables you to delete files that are not synced to the
<br/> client workspace. The files should be specified using depot syntax;
<br/> since the files are not synced, client syntax or local syntax are
<br/> inappropriate and could introduce ambiguities in the file list.
<br/> Note, though, that if the files ARE synced, 'delete -v' will remove
<br/> the files from the client in addition to opening them for delete.
<br/> The preferred way to delete a set of files without transferring
<br/> them to your machine is: 'sync -k file...', then 'delete -k file...'
<br/>
<br/> 'p4 delete' is not supported for files with propagating attributes
<br/> from an edge server in a distributed environment.
<br/>
<br/>
</remarks>
</member>
<member name="T:Perforce.P4.EditFilesCmdFlags">
<summary>
Flags for the edit command.
</summary>
</member>
<member name="F:Perforce.P4.EditFilesCmdFlags.None">
<summary>
No flags.
</summary>
</member>
<member name="F:Perforce.P4.EditFilesCmdFlags.PreviewOnly">
<summary>
The -n flag, previews the operation without changing any files or
metadata.
</summary>
</member>
<member name="F:Perforce.P4.EditFilesCmdFlags.ServerOnly">
<summary>
The -k flag, updates metadata without transferring files to the
workspace.
</summary>
</member>
<member name="T:Perforce.P4.EditCmdOptions">
<summary>
Options for the edit command
</summary>
</member>
<member name="M:Perforce.P4.EditCmdOptions.#ctor(Perforce.P4.EditFilesCmdFlags,System.Int32,Perforce.P4.FileType)">
<summary>
Options for the edit command
</summary>
<param name="flags"></param>
<param name="changeList"></param>
<param name="fileType"></param>
<returns></returns>
<remarks>
<br/><b>p4 help edit</b>
<br/>
<br/> edit -- Open an existing file for edit
<br/>
<br/> p4 edit [-c changelist#] [-k -n] [-t filetype] file ...
<br/>
<br/> Open an existing file for edit. The server records the fact that
<br/> the current user has opened the file in the current workspace, and
<br/> changes the file permission from read-only to read/write.
<br/>
<br/> If -c changelist# is included, the file opened in the specified
<br/> pending changelist. If changelist number is omitted, the file is
<br/> opened in the 'default' changelist.
<br/>
<br/> If -t filetype is specified, the file is assigned that Perforce
<br/> filetype. Otherwise, the filetype of the previous revision is reused.
<br/> If a partial filetype is specified, it is combined with the current
<br/> filetype.For details, see 'p4 help filetypes'.
<br/> Using a filetype of 'auto' will cause the filetype to be chosen
<br/> as if the file were being added, that is the typemap will be
<br/> considered and the file contents may be examined.
<br/>
<br/> The -n flag previews the operation without changing any files or
<br/> metadata.
<br/>
<br/> The -k flag updates metadata without transferring files to the
<br/> workspace. This option can be used to tell the server that files in
<br/> a client workspace are already editable, even if they are not in the
<br/> client view. Typically this flag is used to correct the Perforce
<br/> server when it is wrong about the state of files in the client
<br/> workspace, but incorrect use of this option can result in inaccurate
<br/> file status information.
<br/>
<br/> 'p4 edit' is not supported for files with propagating attributes
<br/> from an edge server in a distributed environment.
<br/>
<br/>
</remarks>
</member>
<member name="T:Perforce.P4.IntegrateFilesCmdFlags">
<summary>
Flags for the integrate command.
</summary>
</member>
<member name="F:Perforce.P4.IntegrateFilesCmdFlags.None">
<summary>
No flags.
</summary>
</member>
<!-- Badly formed XML comment ignored for member "F:Perforce.P4.IntegrateFilesCmdFlags.Force" -->
<member name="F:Perforce.P4.IntegrateFilesCmdFlags.BranchIfTargetDeleted">
<summary>
-Dt If the target file has been deleted and the source
file has changed, re-branch the source file on top
of the target file.
</summary>
</member>
<member name="F:Perforce.P4.IntegrateFilesCmdFlags.DeleteIfSourceDeleted">
<summary>
-Ds If the source file has been deleted and the target
file has changed, delete the target file.
</summary>
</member>
<member name="F:Perforce.P4.IntegrateFilesCmdFlags.IntegrateAllIfSourceDeleted">
<summary>
-Di If the source file has been deleted and re-added,
attempt to integrate all outstanding revisions
of the file, including revisions prior to the
delete. By default, 'p4 integrate' only considers
revisions since the last add.
</summary>
</member>
<member name="F:Perforce.P4.IntegrateFilesCmdFlags.LeaveHaveVersion">
<summary>
The -h flag leaves the target files at the revision currently synced
to the client (the '#have' revision). By default, target files are
automatically synced to the head revision by 'p4 integrate'.
</summary>
</member>
<!-- Badly formed XML comment ignored for member "F:Perforce.P4.IntegrateFilesCmdFlags.IntegrateUnrelated" -->
<member name="F:Perforce.P4.IntegrateFilesCmdFlags.DisplayBaseFile">
<summary>
The -o flag displays the base file name and revision that will be
used in subsequent resolves if a resolve is needed.
</summary>
</member>
<member name="F:Perforce.P4.IntegrateFilesCmdFlags.PreviewIntegrationsOnly">
<summary>
The -n flag displays a preview of required integrations.
</summary>
</member>
<member name="F:Perforce.P4.IntegrateFilesCmdFlags.SwapSourceAndTarget">
<summary>
The -r flag reverses the mappings in the branch view, with the
target files and source files exchanging place. The -b branch
flag is required.
</summary>
</member>
<!-- Badly formed XML comment ignored for member "F:Perforce.P4.IntegrateFilesCmdFlags.BidirectionalView" -->
<!-- Badly formed XML comment ignored for member "F:Perforce.P4.IntegrateFilesCmdFlags.PropogateType" -->
<member name="F:Perforce.P4.IntegrateFilesCmdFlags.DontCopyNewBranchFiles">
<summary>
The -v flag speeds integration by not syncing newly-branched files to
the client. The files can be synced after they are submitted.
</summary>
</member>
<member name="F:Perforce.P4.IntegrateFilesCmdFlags.BranchResolves">
<summary>
-Rb Schedules 'branch resolves' instead of branching new
target files automatically.
</summary>
</member>
<member name="F:Perforce.P4.IntegrateFilesCmdFlags.DeleteResolves">
<summary>
-Rd Schedules 'delete resolves' instead of deleting
target files automatically.
</summary>
</member>
<member name="F:Perforce.P4.IntegrateFilesCmdFlags.SkipRevisions">
<summary>
-Rs Skips cherry-picked revisions already integrated.
This can improve merge results, but can also cause
multiple resolves per file to be scheduled.
</summary>
</member>
<member name="T:Perforce.P4.IntegrateFilesCmdOptions">
<summary>
Integrate command options
</summary>
</member>
<member name="M:Perforce.P4.IntegrateFilesCmdOptions.#ctor(Perforce.P4.IntegrateFilesCmdFlags,System.Int32,System.Int32,System.String,System.String,System.String)">
<summary>
Options for the integrate command.
</summary>
<param name="fromFile"></param>
<returns></returns>
<remarks>
<br/><b>p4 help integrate</b>
<br/>
<br/> integrate -- Integrate one set of files into another
<br/>
<br/> p4 integrate [options] fromFile[revRange] toFile
<br/> p4 integrate [options] -b branch [-r] [toFile[revRange] ...]
<br/> p4 integrate [options] -b branch -s fromFile[revRange] [toFile ...]
<br/> p4 integrate [options] -S stream [-r] [-P parent] [file[revRange] ...]
<br/>
<br/> options: -c changelist# -Di -f -h -O<flags> -n -m max -R<flags> -q -v
<br/>
<br/> 'p4 integrate' integrates one set of files (the 'source') into
<br/> another (the 'target').
<br/>
<br/> (See also 'p4 merge' and 'p4 copy', variants of 'p4 integrate' that
<br/> may be easier and more effective for the task at hand.)
<br/>
<br/> Using the client workspace as a staging area, 'p4 integrate' adds and
<br/> deletes target files per changes in the source, and schedules all
<br/> other affected target files to be resolved. Target files outside of
<br/> the current client view are not affected. Source files need not be
<br/> within the client view.
<br/>
<br/> 'p4 resolve' must be used to merge file content, and to resolve
<br/> filename and filetype changes. 'p4 submit' commits integrated files
<br/> to the depot. Unresolved files may not be submitted. Integrations
<br/> can be shelved with 'p4 shelve' and abandoned with 'p4 revert'. The
<br/> commands 'p4 integrated' and 'p4 filelog' display integration history.
<br/>
<br/> When 'p4 integrate' schedules a workspace file to be resolved, it
<br/> leaves it read-only. 'p4 resolve' can operate on a read-only file.
<br/> For other pre-submit changes, 'p4 edit' must be used to make the
<br/> file writable.
<br/>
<br/> Source and target files can be specified either on the 'p4 integrate'
<br/> command line or through a branch view. On the command line, fromFile
<br/> is the source file set and toFile is the target file set. With a
<br/> branch view, one or more toFile arguments can be given to limit the
<br/> scope of the target file set.
<br/>
<br/> revRange is a revision or a revision range that limits the span of
<br/> source history to be probed for unintegrated revisions. revRange
<br/> can be used on fromFile, or on toFile, but not on both. When used on
<br/> toFile, it refers to source revisions, not to target revisions. For
<br/> details about revision specifiers, see 'p4 help revisions'.
<br/>
<br/> The -S flag makes 'p4 integrate' use a generated branch view that maps
<br/> a stream (or its underlying real stream) to its parent. With -r, the
<br/> direction of the mapping is reversed. -P can be used to generate the
<br/> branch view using a parent stream other than the stream's actual
<br/> parent. Note that to submit integrated stream files, the current
<br/> client must be switched to the target stream, or to a virtual child
<br/> stream of the target stream.
<br/>
<br/> The -b flag makes 'p4 integrate' use a user-defined branch view.
<br/> (See 'p4 help branch'.) The source is the left side of the branch view
<br/> and the target is the right side. With -r, the direction is reversed.
<br/>
<br/> The -s flag can be used with -b to cause fromFile to be treated as
<br/> the source, and both sides of the branch view to be treated as the
<br/> target, per the branch view mapping. Optional toFile arguments may
<br/> be given to further restrict the scope of the target file set. The
<br/> -r flag is ignored when -s is used.
<br/>
<br/> Note that 'p4 integrate' automatically adusts source-to-target
<br/> mappings for moved and renamed files. (Adjustment occurs only if
<br/> the 'p4 move' command was used to move/rename files.) The scope of
<br/> source and target file sets must include both the old-named and the
<br/> new-named files for mappings to be adjusted. A filename resolve is
<br/> scheduled for each remapped file to allow the target to be moved to
<br/> match the source.
<br/>
<br/> The -f flag forces integrate to ignore integration history and treat
<br/> all source revisions as unintegrated. It is meant to be used with
<br/> revRange to force reintegration of specific, previously integrated
<br/> revisions.
<br/>
<br/> The -O flags cause more information to be output for each file opened:
<br/>
<br/> -Ob Show the base revision for the merge (if any).
<br/> -Or Show the resolve(s) that are being scheduled.
<br/>
<br/> The -R flags modify the way resolves are scheduled:
<br/>
<br/> -Rb Schedules 'branch resolves' instead of branching new
<br/> target files automatically.
<br/>
<br/> -Rd Schedules 'delete resolves' instead of deleting
<br/> target files automatically.
<br/>
<br/> -Rs Skips cherry-picked revisions already integrated.
<br/> This can improve merge results, but can also cause
<br/> multiple resolves per file to be scheduled.
<br/>
<br/> The -Di flag modifies the way deleted revisions are treated. If the
<br/> source file has been deleted and re-added, revisions that precede
<br/> the deletion will be considered to be part of the same source file.
<br/> By default, re-added files are considered to be unrelated to the
<br/> files of the same name that preceded them.
<br/>
<br/> The -h flag leaves the target files at the revision currently synced
<br/> to the client (the '#have' revision). By default, target files are
<br/> automatically synced to the head revision by 'p4 integrate'.
<br/>
<br/> The -m flag limits integration to the first 'max' number of files.
<br/>
<br/> The -n flag displays a preview of integration, without actually
<br/> doing anything.
<br/>
<br/> The -q flag suppresses normal output messages. Messages regarding
<br/> errors or exceptional conditions are displayed.
<br/>
<br/> If -c changelist# is specified, the files are opened in the
<br/> designated numbered pending changelist instead of the 'default'
<br/> changelist.
<br/>
<br/> The -v flag causes a 'virtual' integration that does not modify
<br/> client workspace files unless target files need to be resolved.
<br/> After submitting a virtual integration, 'p4 sync' can be used to
<br/> update the workspace.
<br/>
<br/> Integration is not supported for files with propagating attributes
<br/> from an edge server in a distributed environment. Depending on the
<br/> integration action, target, and source, either the integration or
<br/> resolve command will fail.
<br/>
<br/>
</remarks>
</member>
<member name="T:Perforce.P4.LabelSyncCmdFlags">
<summary>
Flags for the label sync command.
</summary>
</member>
<member name="F:Perforce.P4.LabelSyncCmdFlags.None">
<summary>
No flags.
</summary>
</member>
<member name="F:Perforce.P4.LabelSyncCmdFlags.AddFile">
<summary>
The -a flag adds the specified file to the label.
</summary>
</member>
<member name="F:Perforce.P4.LabelSyncCmdFlags.DeleteFile">
<summary>
The -d deletes the specified file from the label, regardless of
revision.
</summary>
</member>
<member name="F:Perforce.P4.LabelSyncCmdFlags.Preview">
<summary>
The -n flag previews the operation without altering the label.
</summary>
</member>
<member name="F:Perforce.P4.LabelSyncCmdFlags.Quiet">
<summary>
The -q flag suppresses normal output messages. Messages regarding
errors or exceptional conditions are displayed.
</summary>
</member>
<member name="T:Perforce.P4.LabelSyncCmdOptions">
<summary>
Labelsync command options
</summary>
</member>
<member name="M:Perforce.P4.LabelSyncCmdOptions.#ctor(Perforce.P4.LabelSyncCmdFlags)">
<summary>
Options for the labelsync command.
</summary>
<param name="flags"></param>
<param name="labelName"></param>
<returns></returns>
<remarks>
<br/><b>p4 help labelsync</b>
<br/>
<br/> labelsync -- Apply the label to the contents of the client workspace
<br/>
<br/> p4 labelsync [-a -d -g -n -q] -l label [file[revRange] ...]
<br/>
<br/> Labelsync causes the specified label to reflect the current contents
<br/> of the client. It records the revision of each file currently synced.
<br/> The label's name can subsequently be used in a revision specification
<br/> as @label to refer to the revision of a file as stored in the label.
<br/>
<br/> Without a file argument, labelsync causes the label to reflect the
<br/> contents of the whole client, by adding, deleting, and updating the
<br/> label. If a file is specified, labelsync updates the specified file.
<br/>
<br/> If the file argument includes a revision specification, that revision
<br/> is used instead of the revision synced by the client. If the specified
<br/> revision is a deleted revision, the label includes that deleted
<br/> revision. See 'p4 help revisions' for details about specifying
<br/> revisions.
<br/>
<br/> If the file argument includes a revision range specification,
<br/> only files selected by the revision range are updated, and the
<br/> highest revision in the range is used.
<br/>
<br/> The -a flag adds the specified file to the label.
<br/>
<br/> The -d deletes the specified file from the label, regardless of
<br/> revision.
<br/>
<br/> The -n flag previews the operation without altering the label.
<br/>
<br/> Only the owner of a label can run labelsync on that label. A label
<br/> that has its Options: field set to 'locked' cannot be updated. A
<br/> label without an owner can be labelsync'd by any user.
<br/>
<br/> The -q flag suppresses normal output messages. Messages regarding
<br/> errors or exceptional conditions are displayed.
<br/>
<br/> The -g flag should be used on an Edge Server to update a global
<br/> label. Note that in this case, the client should be a global client.
<br/> Configuring rpl.labels.global=1 reverses this default and causes this
<br/> flag to have the opposite meaning.
<br/>
<br/>
</remarks>
</member>
<member name="T:Perforce.P4.LockCmdOptions">
<summary>
Lock command options
</summary>
</member>
<member name="M:Perforce.P4.LockCmdOptions.#ctor(System.Int32)">
<summary>
Options for the lock command.
</summary>
<param name="changeList"></param>
<returns></returns>
<remarks>
<br/><b>p4 help lock</b>
<br/>
<br/> lock -- Lock an open file to prevent it from being submitted
<br/>
<br/> p4 lock [-c changelist#] [file ...]
<br/>
<br/> The specified files are locked in the depot, preventing any user
<br/> other than the current user on the current client from submitting
<br/> changes to the files. If a file is already locked, the lock request
<br/> is rejected. If no file names are specified, all files in the
<br/> specified changelist are locked. If changelist number is omitted,
<br/> files in the default changelist are locked.
<br/>
<br/>
</remarks>
</member>
<member name="T:Perforce.P4.MoveFileCmdFlags">
<summary>
Flags for the move command.
</summary>
</member>
<member name="F:Perforce.P4.MoveFileCmdFlags.None">
<summary>
No flags.
</summary>
</member>
<member name="F:Perforce.P4.MoveFileCmdFlags.Force">
<summary>
The -f flag forces a move to an existing target file. The file
must be synced and not opened. The originating source file will
no longer be synced to the client.
</summary>
</member>
<member name="F:Perforce.P4.MoveFileCmdFlags.Preview">
<summary>
The -n flag previews the operation without moving files.
</summary>
</member>
<member name="F:Perforce.P4.MoveFileCmdFlags.ServerOnly">
<summary>
The -k flag performs the rename on the server without modifying
client files. Use with caution, as an incorrect move can cause
discrepancies between the state of the client and the corresponding
server metadata.
</summary>
</member>
<member name="T:Perforce.P4.MoveCmdOptions">
<summary>
Move command options
</summary>
</member>
<member name="M:Perforce.P4.MoveCmdOptions.#ctor(Perforce.P4.MoveFileCmdFlags,System.Int32,Perforce.P4.FileType)">
<summary>
Options for the move command.
</summary>
<param name="flags"></param>
<param name="changeList"></param>
<param name="fileType"></param>
<returns></returns>
<remarks>
<br/><b>p4 help move</b>
<br/>
<br/> move -- move file(s) from one location to another
<br/> rename -- synonym for 'move'
<br/>
<br/> p4 move [-c changelist#] [-f -n -k] [-t filetype] fromFile toFile
<br/>
<br/> Move takes an already opened file and moves it from one client
<br/> location to another, reopening it as a pending depot move. When
<br/> the file is submitted with 'p4 submit', its depot file is moved
<br/> accordingly.
<br/>
<br/> Wildcards in fromFile and toFile must match. The fromFile must be
<br/> a file open for add or edit.
<br/>
<br/> 'p4 opened' lists pending moves. 'p4 diff' can compare a moved
<br/> client file with its depot original, 'p4 sync' can schedule an
<br/> update of a moved file, and 'p4 resolve' can resolve the update.
<br/>
<br/> A client file can be moved many times before it is submitted.
<br/> Moving a file back to its original location will undo a pending
<br/> move, leaving unsubmitted content intact. Using 'p4 revert'
<br/> undoes the move and reverts the unsubmitted content.
<br/>
<br/> If -c changelist# is specified, the file is reopened in the
<br/> specified pending changelist as well as being moved.
<br/>
<br/> The -f flag forces a move to an existing target file. The file
<br/> must be synced and not opened. The originating source file will
<br/> no longer be synced to the client.
<br/>
<br/> If -t filetype is specified, the file is assigned that filetype.
<br/> If the filetype is a partial filetype, the partial filetype is
<br/> combined with the current filetype. See 'p4 help filetypes'.
<br/>
<br/> The -n flag previews the operation without moving files.
<br/>
<br/> The -k flag performs the rename on the server without modifying
<br/> client files. Use with caution, as an incorrect move can cause
<br/> discrepancies between the state of the client and the corresponding
<br/> server metadata.
<br/>
<br/> The 'move' command requires a release 2009.1 or newer client. The
<br/> '-f' flag requires a 2010.1 client.
<br/>
<br/>
</remarks>
</member>
<member name="T:Perforce.P4.ReopenCmdOptions">
<summary>
Options for the reopen command.
</summary>
</member>
<member name="M:Perforce.P4.ReopenCmdOptions.#ctor(System.Int32,Perforce.P4.FileType)">
<summary>
Options for the reopen command.
</summary>
<param name="changeList"></param>
<param name="fileType"></param>
<returns></returns>
<remarks>
<br/><b>p4 help reopen</b>
<br/>
<br/> reopen -- Change the filetype of an open file or move it to
<br/> another changelist
<br/>
<br/> p4 reopen [-c changelist#] [-t filetype] file ...
<br/>
<br/> Reopen an open file for the current user in order to move it to a
<br/> different changelist or change its filetype.
<br/>
<br/> The target changelist must exist; you cannot create a changelist by
<br/> reopening a file. To move a file to the default changelist, use
<br/> 'p4 reopen -c default'.
<br/>
<br/> If -t filetype is specified, the file is assigned that filetype. If
<br/> a partial filetype is specified, it is combined with the current
<br/> filetype. For details, see 'p4 help filetypes'.
<br/>
<br/>
</remarks>
</member>
<member name="T:Perforce.P4.ResolveFilesCmdFlags">
<summary>
Flags for the resolve command.
</summary>
</member>
<member name="F:Perforce.P4.ResolveFilesCmdFlags.None">
<summary>
No flags.
</summary>
</member>
<member name="F:Perforce.P4.ResolveFilesCmdFlags.FileAttributesOnly">
<summary>
The -A flag can be used to limit the kind of resolving that will be
attempted; without it, everything is attempted:
-Aa Resolve attributes.
</summary>
</member>
<member name="F:Perforce.P4.ResolveFilesCmdFlags.FileBranchingOnly">
<summary>
The -A flag can be used to limit the kind of resolving that will be
attempted; without it, everything is attempted:
-Ab Resolve file branching.
</summary>
</member>
<member name="F:Perforce.P4.ResolveFilesCmdFlags.FileContentChangesOnly">
<summary>
The -A flag can be used to limit the kind of resolving that will be
attempted; without it, everything is attempted:
-Ac Resolve file content changes.
</summary>
</member>
<member name="F:Perforce.P4.ResolveFilesCmdFlags.FileDeletionsOnly">
<summary>
The -A flag can be used to limit the kind of resolving that will be
attempted; without it, everything is attempted:
-Ad Resolve file deletions.
</summary>
</member>
<member name="F:Perforce.P4.ResolveFilesCmdFlags.FileMovesOnly">
<summary>
The -A flag can be used to limit the kind of resolving that will be
attempted; without it, everything is attempted:
-Am Resolve moved and renamed files.
</summary>
</member>
<member name="F:Perforce.P4.ResolveFilesCmdFlags.FileTypeChangesOnly">
<summary>
The -A flag can be used to limit the kind of resolving that will be
attempted; without it, everything is attempted:
-At Resolve filetype changes.
</summary>
</member>
<member name="F:Perforce.P4.ResolveFilesCmdFlags.AutomaticSafeMode">
<summary>
The -a flag puts 'p4 resolve' into automatic mode. The user is not
prompted, and files that can't be resolved automatically are skipped:
-as 'Safe' resolve; skip files that need merging.
The -as flag causes the workspace file to be replaced with their file
only if theirs has changed and yours has not.
</summary>
</member>
<member name="F:Perforce.P4.ResolveFilesCmdFlags.AutomaticMergeMode">
<summary>
The -a flag puts 'p4 resolve' into automatic mode. The user is not
prompted, and files that can't be resolved automatically are skipped:
-am Resolve by merging; skip files with conflicts.
The -am flag causes the workspace file to be replaced with the result
of merging theirs with yours. If the merge detected conflicts, the
file is left untouched and unresolved.
</summary>
</member>
<member name="F:Perforce.P4.ResolveFilesCmdFlags.AutomaticForceMergeMode">
<summary>
The -a flag puts 'p4 resolve' into automatic mode. The user is not
prompted, and files that can't be resolved automatically are skipped:
-af Force acceptance of merged files with conflicts.
The -af flag causes the workspace file to be replaced with the result
of merging theirs with yours, even if there were conflicts. This can
leave conflict markers in workspace files.
</summary>
</member>
<member name="F:Perforce.P4.ResolveFilesCmdFlags.AutomaticTheirsMode">
<summary>
The -a flag puts 'p4 resolve' into automatic mode. The user is not
prompted, and files that can't be resolved automatically are skipped:
-at Force acceptance of theirs; overwrites yours.
The -at flag resolves all files by copying theirs into yours. It
should be used with care, as it overwrites any changes made to the
file in the client workspace.
</summary>
</member>
<member name="F:Perforce.P4.ResolveFilesCmdFlags.AutomaticYoursMode">
<summary>
The -a flag puts 'p4 resolve' into automatic mode. The user is not
prompted, and files that can't be resolved automatically are skipped:
-ay Force acceptance of yours; ignores theirs.
The -ay flag resolves all files by accepting yours and ignoring
theirs. It preserves the content of workspace files.
</summary>
</member>
<member name="F:Perforce.P4.ResolveFilesCmdFlags.ForceResolve">
<summary>
The -f flag enables previously resolved files to be resolved again.
By default, after files have been resolved, 'p4 resolve' does not
process them again.
</summary>
</member>
<member name="F:Perforce.P4.ResolveFilesCmdFlags.PreviewOnly">
<summary>
The -n flag previews the operation without altering files.
</summary>
</member>
<member name="F:Perforce.P4.ResolveFilesCmdFlags.PreviewPlusOnly">
<summary>
The -N flag previews the operation with additional information about
any non-content resolve actions that are scheduled.
</summary>
</member>
<member name="F:Perforce.P4.ResolveFilesCmdFlags.DisplayBaseFile">
<summary>
The -o flag displays the base file name and revision to be used
during the the merge.
</summary>
</member>
<member name="F:Perforce.P4.ResolveFilesCmdFlags.ForceTextualMerge">
<summary>
The -t flag forces 'p4 resolve' to attempt a textual merge, even for
files with non-text (binary) types.
</summary>
</member>
<member name="F:Perforce.P4.ResolveFilesCmdFlags.MarkAllChanges">
<summary>
The -v flag causes 'p4 resolve' to insert markers for all changes,
not just conflicts.
</summary>
</member>
<member name="F:Perforce.P4.ResolveFilesCmdFlags.IgnoreWhitespaceChanges">
<summary>
The -d flags can be used to control handling of whitespace and line
endings when merging files:
-db Ignore Whitespace Changes
</summary>
</member>
<member name="F:Perforce.P4.ResolveFilesCmdFlags.IgnoreWhitespace">
<summary>
The -d flags can be used to control handling of whitespace and line
endings when merging files:
-dw Ingore whitespace altogether.
</summary>
</member>
<member name="F:Perforce.P4.ResolveFilesCmdFlags.IgnoreLineEndings">
<summary>
The -d flags can be used to control handling of whitespace and line
endings when merging files:
-dl Ignore Line Endings
</summary>
</member>
<member name="T:Perforce.P4.ResolveCmdOptions">
<summary>
Options for the resolve command.
</summary>
</member>
<member name="M:Perforce.P4.ResolveCmdOptions.#ctor(Perforce.P4.ResolveFilesCmdFlags,System.Int32)">
<summary>
Options for the resolve command.
</summary>
<param name="changeList"></param>
<param name="fileType"></param>
<returns></returns>
<remarks>
<br/><b>p4 help resolve</b>
<br/>
<br/> resolve -- Resolve integrations and updates to workspace files
<br/>
<br/> p4 resolve [options] [file ...]
<br/>
<br/> options: -A<flags> -a<flags> -d<flags> -f -n -N -o -t -v
<br/> -c changelist#
<br/>
<br/> 'p4 resolve' resolves changes to files in the client workspace.
<br/>
<br/> 'p4 resolve' works only on files that have been scheduled to be
<br/> resolved. The commands that can schedule resolves are: 'p4 sync',
<br/> 'p4 update', 'p4 submit', 'p4 merge', and 'p4 integrate'. Files must
<br/> be resolved before they can be submitted.
<br/>
<br/> Resolving involves two sets of files, a source and a target. The
<br/> target is a set of depot files that maps to opened files in the
<br/> client workspace. When resolving an integration, the source is a
<br/> different set of depot files than the target. When resolving an
<br/> update, the source is the same set of depot files as the target,
<br/> at a different revision.
<br/>
<br/> The 'p4 resolve' file argument specifies the target. If the file
<br/> argument is omitted, all unresolved files are resolved.
<br/>
<br/> Resolving can modify workspace files. To back up files, use 'p4
<br/> shelve' before using 'p4 resolve'.
<br/>
<br/> The resolve process is a classic three-way merge. The participating
<br/> files are referred to as follows:
<br/>
<br/> 'yours' The target file open in the client workspace
<br/> 'theirs' The source file in the depot
<br/> 'base' The common ancestor; the highest revision of the
<br/> source file already accounted for in the target.
<br/> 'merged' The merged result.
<br/>
<br/> Filenames, filetypes, and text file content can be resolved by
<br/> accepting 'yours', 'theirs', or 'merged'. Branching, deletion, and
<br/> binary file content can be resolved by accepting either 'yours' or
<br/> 'theirs'.
<br/>
<br/> When resolving integrated changes, 'p4 resolve' distinguishes among
<br/> four results: entirely yours, entirely theirs, a pure merge, or an
<br/> edited merge. The distinction is recorded when resolved files are
<br/> submitted, and will be used by future commands to determine whether
<br/> integration is needed.
<br/>
<br/> In all cases, accepting 'yours' leaves the target file in its current
<br/> state. The result of accepting 'theirs' is as follows:
<br/>
<br/> Content: The target file content is overwritten.
<br/> Attribute: The target's attributes are replaced.
<br/> Branching: A new target is branched.
<br/> Deletion: The target file is deleted.
<br/> Filename: The target file is moved or renamed.
<br/> Filetype: The target file's type is changed.
<br/>
<br/> For each unresolved change, the user is prompted to accept a result.
<br/> Content and non-content changes are resolved separately. For content,
<br/> 'p4 resolve' places the merged result into a temporary file in the
<br/> client workspace. If there are any conflicts, the merged file contains
<br/> conflict markers that must be removed by the user.
<br/>
<br/> 'p4 resolve' displays a count of text diffs and conflicts, and offers
<br/> the following prompts:
<br/>
<br/> Accept:
<br/> at Keep only changes to their file.
<br/> ay Keep only changes to your file.
<br/> * am Keep merged file.
<br/> * ae Keep merged and edited file.
<br/> * a Keep autoselected file.
<br/>
<br/> Diff:
<br/> * dt See their changes alone.
<br/> * dy See your changes alone.
<br/> * dm See merged changes.
<br/> d Diff your file against merged file.
<br/>
<br/> Edit:
<br/> et Edit their file (read only).
<br/> ey Edit your file (read/write).
<br/> * e Edit merged file (read/write).
<br/>
<br/> Misc:
<br/> * m Run '$P4MERGE base theirs yours merged'.
<br/> (Runs '$P4MERGEUNICODE charset base theirs
<br/> yours merged' if set and the file is a
<br/> unicode file.)
<br/> s Skip this file.
<br/> h Print this help message.
<br/> ^C Quit the resolve operation.
<br/>
<br/> Options marked (*) appear only for text files. The suggested action
<br/> will be displayed in brackets.
<br/>
<br/> The 'merge' (m) option enables you to invoke your own merge program, if
<br/> one is configured using the $P4MERGE environment variable. Four files
<br/> are passed to the program: the base, yours, theirs, and the temporary
<br/> file. The program is expected to write merge results to the temporary
<br/> file.
<br/>
<br/> The -A flag can be used to limit the kind of resolving that will be
<br/> attempted; without it, everything is attempted:
<br/>
<br/> -Aa Resolve attributes.
<br/> -Ab Resolve file branching.
<br/> -Ac Resolve file content changes.
<br/> -Ad Resolve file deletions.
<br/> -Am Resolve moved and renamed files.
<br/> -At Resolve filetype changes.
<br/> -AQ Resolve charset changes.
<br/>
<br/> The -a flag puts 'p4 resolve' into automatic mode. The user is not
<br/> prompted, and files that can't be resolved automatically are skipped:
<br/>
<br/> -as 'Safe' resolve; skip files that need merging.
<br/> -am Resolve by merging; skip files with conflicts.
<br/> -af Force acceptance of merged files with conflicts.
<br/> -at Force acceptance of theirs; overwrites yours.
<br/> -ay Force acceptance of yours; ignores theirs.
<br/>
<br/> The -as flag causes the workspace file to be replaced with their file
<br/> only if theirs has changed and yours has not.
<br/>
<br/> The -am flag causes the workspace file to be replaced with the result
<br/> of merging theirs with yours. If the merge detected conflicts, the
<br/> file is left untouched and unresolved.
<br/>
<br/> The -af flag causes the workspace file to be replaced with the result
<br/> of merging theirs with yours, even if there were conflicts. This can
<br/> leave conflict markers in workspace files.
<br/>
<br/> The -at flag resolves all files by copying theirs into yours. It
<br/> should be used with care, as it overwrites any changes made to the
<br/> file in the client workspace.
<br/>
<br/> The -ay flag resolves all files by accepting yours and ignoring
<br/> theirs. It preserves the content of workspace files.
<br/>
<br/> The -d flags can be used to control handling of whitespace and line
<br/> endings when merging files:
<br/>
<br/> -db Ignore whitespace changes.
<br/> -dw Ignore whitespace altogether.
<br/> -dl Ignores line endings.
<br/>
<br/> The -d flags are also passed to the diff options in the 'p4 resolve'
<br/> dialog. Additional -d flags that modify the diff output but do not
<br/> modify merge behavior include -dn (RCS), -dc (context), -ds (summary),
<br/> and -du (unified). Note that 'p4 resolve' uses text from the client
<br/> file if the files differ only in whitespace.
<br/>
<br/> The -f flag enables previously resolved content to be resolved again.
<br/> By default, after files have been resolved, 'p4 resolve' does not
<br/> process them again.
<br/>
<br/> The -n flag previews the operation without altering files.
<br/>
<br/> The -N flag previews the operation with additional information about
<br/> any non-content resolve actions that are scheduled.
<br/>
<br/> The -o flag displays the base file name and revision to be used
<br/> during the the merge.
<br/>
<br/> The -t flag forces 'p4 resolve' to attempt a textual merge, even for
<br/> files with non-text (binary) types.
<br/>
<br/> The -v flag causes 'p4 resolve' to insert markers for all changes,
<br/> not just conflicts.
<br/>
<br/> The -c flag limits 'p4 resolve' to the files in changelist#.
<br/>
<br/> 'p4 resolve' is not supported for files with propagating attributes
<br/> from an edge server in a distributed environment.
<br/>
<br/>
</remarks>
</member>
<member name="T:Perforce.P4.DiffWhiteSpaceOptions">
<summary>
Diff whitespace options flags.
</summary>
</member>
<member name="F:Perforce.P4.DiffWhiteSpaceOptions.none">
<summary>
None
</summary>
</member>
<member name="F:Perforce.P4.DiffWhiteSpaceOptions.IgnoreWhitespaceChanges">
<summary>
-db Ignore Whitespace Changes
</summary>
</member>
<member name="F:Perforce.P4.DiffWhiteSpaceOptions.IgnoreWhitespace">
<summary>
-dw Ingore whitespace altogether.
</summary>
</member>
<member name="F:Perforce.P4.DiffWhiteSpaceOptions.IgnoreLineEndings">
<summary>
-dl Ignore Line Endings
</summary>
</member>
<member name="F:Perforce.P4.DiffWhiteSpaceOptions.RCS">
<summary>
-dn RCS
</summary>
</member>
<member name="F:Perforce.P4.DiffWhiteSpaceOptions.ShowContext">
<summary>
-dc[n] Show context of changes
</summary>
</member>
<member name="F:Perforce.P4.DiffWhiteSpaceOptions.ShowSummary">
<summary>
-ds Summary
</summary>
</member>
<member name="F:Perforce.P4.DiffWhiteSpaceOptions.ShowUnified">
<summary>
-du[n] Unified
</summary>
</member>
<member name="T:Perforce.P4.SubmitFilesCmdFlags">
<summary>
Flags for the submit command.
</summary>
</member>
<member name="F:Perforce.P4.SubmitFilesCmdFlags.None">
<summary>
No flags.
</summary>
</member>
<member name="F:Perforce.P4.SubmitFilesCmdFlags.ReopenFiles">
<summary>
The -r flag reopens submitted files in the default changelist after
submission.
</summary>
</member>
<member name="F:Perforce.P4.SubmitFilesCmdFlags.IncludeJobs">
<summary>
The -s flag extends the list of jobs to include the fix status
for each job, which becomes the job's status when the changelist
is committed. See 'p4 help change' for details.
submission.
</summary>
</member>
<member name="F:Perforce.P4.SubmitFilesCmdFlags.SubmitShelved">
<summary>
The -e flag submits a shelved changelist without transferring files
or modifying the workspace. The shelved change must be owned by
the person submitting the change, but the client may be different.
However, files shelved to a stream target may only be submitted by
a stream client that is mapped to the target stream. In addition,
files shelved to a non-stream target cannot be submitted by a
stream client. Submitting shelved changes by a task stream
client is not supported. To submit a shelved change, all
files in the shelved change must be up to date and resolved. No
files may be open in any workspace at the same change number.
Client submit options (ie revertUnchanged, etc) will be ignored.
If the submit is successful, the shelved change and files
are cleaned up, and are no longer available to be unshelved or
submitted.
</summary>
</member>
<member name="T:Perforce.P4.SubmitCmdOptions">
<summary>
Submit command options
</summary>
</member>
<member name="M:Perforce.P4.SubmitCmdOptions.#ctor(Perforce.P4.SubmitFilesCmdFlags,System.Int32,Perforce.P4.Changelist,System.String,Perforce.P4.ClientSubmitOptions)">
<summary>
Submit command options
</summary>
<param name="flags"></param>
<param name="changelist"></param>
<param name="newChangelist"></param>
<param name="description"></param>
<param name="submitOptions"></param>
<returns></returns>
<remarks>
<br/><b>p4 help submit</b>
<br/>
<br/> submit -- Submit open files to the depot
<br/>
<br/> p4 submit [-r -s -f option --noretransfer 0|1]
<br/> p4 submit [-r -s -f option] file
<br/> p4 submit [-r -f option] -d description
<br/> p4 submit [-r -f option] -d description file
<br/> p4 submit [-r -f option --noretransfer 0|1] -c changelist#
<br/> p4 submit -e shelvedChange#
<br/> p4 submit -i [-r -s -f option]
<br/> --parallel=threads=N[,batch=N][,min=N]
<br/>
<br/> 'p4 submit' commits a pending changelist and its files to the depot.
<br/>
<br/> By default, 'p4 submit' attempts to submit all files in the 'default'
<br/> changelist. Submit displays a dialog where you enter a description
<br/> of the change and, optionally, delete files from the list of files
<br/> to be checked in.
<br/>
<br/> To add files to a changelist before submitting, use any of the
<br/> commands that open client workspace files: 'p4 add', 'p4 edit',
<br/> etc.
<br/>
<br/> If the file parameter is specified, only files in the default
<br/> changelist that match the pattern are submitted.
<br/>
<br/> Files in a stream path can be submitted only by client workspaces
<br/> dedicated to the stream. See 'p4 help client'.
<br/>
<br/> Before committing a changelist, 'p4 submit' locks all the files being
<br/> submitted. If any file cannot be locked or submitted, the files are
<br/> left open in a numbered pending changelist. By default, the files in
<br/> a failed submit operation are left locked unless the
<br/> submit.unlocklocked configurable is set. Files are unlocked even if
<br/> they were manually locked prior to submit if submit fails when
<br/> submit.unlocklocked is set. 'p4 opened' shows unsubmitted files
<br/> and their changelists.
<br/>
<br/> Submit is atomic: if the operation succeeds, all files are updated
<br/> in the depot. If the submit fails, no depot files are updated.
<br/>
<br/> If submit fails, some or all of the files may have been copied to
<br/> the server. By default, retrying a failed submit will transfer all of
<br/> the files again unless the submit.noretransfer configurable is set.
<br/> If submit.noretransfer is set to 1, submit uses digest comparisons to
<br/> to detect if the files have already been transferred in order to
<br/> avoid file re-transfer when retrying a failed submit.
<br/>
<br/> The --noretransfer flag is used to override the submit.noretransfer
<br/> configurable so the user can choose his preferred re-transfer
<br/> behavior during the current submit operation.
<br/>
<br/> The -c flag submits the specified pending changelist instead of the
<br/> default changelist. Additional changelists can be created manually,
<br/> using the 'p4 change' command, or automatically as the result of a
<br/> failed attempt to submit the default changelist.
<br/>
<br/> The -e flag submits a shelved changelist without transferring files
<br/> or modifying the workspace. The shelved change must be owned by
<br/> the person submitting the change, but the client may be different.
<br/> However, files shelved to a stream target may only be submitted by
<br/> a stream client that is mapped to the target stream. In addition,
<br/> files shelved to a non-stream target cannot be submitted by a stream
<br/> client. To submit a shelved change, all files in the shelved change
<br/> must be up to date and resolved. No files may be open in any workspace
<br/> at the same change number. Client submit options (ie revertUnchanged,
<br/> etc) will be ignored. If the submit is successful, the shelved change
<br/> and files are cleaned up, and are no longer available to be unshelved
<br/> or submitted.
<br/>
<br/> The -d flag passes a description into the specified changelist rather
<br/> than displaying the changelist dialog for manual editing. This option
<br/> is useful for scripting, but does not allow you to add jobs or modify
<br/> the default changelist.
<br/>
<br/> The -f flag enables you to override submit options that are configured
<br/> for the client that is submitting the changelist. This flag overrides
<br/> the -r (reopen)flag, if it is specified. See 'p4 help client' for
<br/> details about submit options.
<br/>
<br/> The -i flag reads a changelist specification from the standard input.
<br/> The user's editor is not invoked.
<br/>
<br/> The -r flag reopens submitted files in the default changelist after
<br/> submission.
<br/>
<br/> The -s flag extends the list of jobs to include the fix status
<br/> for each job, which becomes the job's status when the changelist
<br/> is committed. See 'p4 help change' for details.
<br/>
<br/> The --parallel flag specifies options for parallel file transfer. If
<br/> parallel file transfer has been enabled by setting the
<br/> net.parallel.max configurable, and if there are sufficient resources
<br/> across the system, a submit command may execute more rapidly by
<br/> transferring multiple files in parallel. Specify threads=N to request
<br/> files be sent concurrently, using N independent network connections.
<br/> The N threads grab work in batches; specify batch=N to control the
<br/> number of files in a batch. A submit that is too small will not
<br/> initiate parallel file transfers; specify min=N to control the
<br/> minimum number of files in a parallel submit. Requesting progress
<br/> indicators causes the --parallel flag to be ignored.
<br/>
<br/> Using --parallel from an edge server allows parallel file transfer
<br/> from the edge server to the commit server. This uses standard pull
<br/> threads to transfer the files. Note that an adminstrator must insure
<br/> that pull threads can be run on the commit server. The address
<br/> used by the commit server to connect to the edge server must
<br/> be specified in the ExternalAddress field of the edge server spec.
<br/>
<br/> Only 'submit -e' is supported for files with propagating attributes
<br/> from an edge server in a distributed environment.
<br/>
<br/>
</remarks>
</member>
<member name="T:Perforce.P4.GetResolvedFilesCmdFlags">
<summary>
Flags for the resolved command.
</summary>
</member>
<member name="F:Perforce.P4.GetResolvedFilesCmdFlags.None">
<summary>
No flags.
</summary>
</member>
<member name="F:Perforce.P4.GetResolvedFilesCmdFlags.IncludeBaseRevision">
<summary>
The -r flag reopens submitted files in the default changelist after
submission.
</summary>
</member>
<member name="T:Perforce.P4.ResolvedCmdOptions">
<summary>
Options for Resolve command
</summary>
</member>
<member name="M:Perforce.P4.ResolvedCmdOptions.#ctor(Perforce.P4.GetResolvedFilesCmdFlags)">
<summary>
Resolved command options.
</summary>
<param name="flags"></param>
<returns></returns>
<remarks>
<br/><b>p4 help resolved</b>
<br/>
<br/> resolved -- Show files that have been resolved but not submitted
<br/>
<br/> p4 resolved [-o] [file ...]
<br/>
<br/> 'p4 resolved' lists file updates and integrations that have been
<br/> resolved but not yet submitted. To see unresolved integrations,
<br/> use 'p4 resolve -n'. To see already submitted integrations, use
<br/> 'p4 integrated'.
<br/>
<br/> If a depot file path is specified, the output lists resolves for
<br/> 'theirs' files that match the specified path. If a client file
<br/> path is specified, the output lists resolves for 'yours' files
<br/> that match the specified path.
<br/>
<br/> The -o flag reports the revision used as the base during the
<br/> resolve.
<br/>
<br/>
</remarks>
</member>
<member name="T:Perforce.P4.RevertFilesCmdFlags">
<summary>
Flags for the revert command.
</summary>
</member>
<member name="F:Perforce.P4.RevertFilesCmdFlags.None">
<summary>
No flags.
</summary>
</member>
<member name="F:Perforce.P4.RevertFilesCmdFlags.UnchangedOnly">
<summary>
The -a flag reverts only files that are open for edit or integrate
and are unchanged or missing. Files with pending integration records
are left open. The file arguments are optional when -a is specified.
</summary>
</member>
<member name="F:Perforce.P4.RevertFilesCmdFlags.Preview">
<summary>
The -n flag displays a preview of the operation.
</summary>
</member>
<member name="F:Perforce.P4.RevertFilesCmdFlags.ServerOnly">
<summary>
The -k flag marks the file as reverted in server metadata without
altering files in the client workspace.
</summary>
</member>
<member name="M:Perforce.P4.RevertCmdOptions.#ctor(Perforce.P4.RevertFilesCmdFlags,System.Int32)">
<summary>
Revert command options.
</summary>
<param name="flags"></param>
<param name="changelist"></param>
<returns></returns>
<remarks>
<br/><b>p4 help revert</b>
<br/>
<br/> revert -- Discard changes from an opened file
<br/>
<br/> p4 revert [-a -n -k -w -c changelist# -C client] file ...
<br/>
<br/> Revert an open file to the revision that was synced from the depot,
<br/> discarding any edits or integrations that have been made. You must
<br/> explicitly specify the files to be reverted. Files are removed from
<br/> the changelist in which they are open. Locked files are unlocked.
<br/>
<br/> The -a flag reverts only files that are open for edit, add, or
<br/> integrate and are unchanged or missing. Files with pending
<br/> integration records are left open. The file arguments are optional
<br/> when -a is specified.
<br/>
<br/> The -n flag displays a preview of the operation.
<br/>
<br/> The -k flag marks the file as reverted in server metadata without
<br/> altering files in the client workspace.
<br/>
<br/> The -w flag causes files that are open for add to be deleted from the
<br/> workspace when they are reverted.
<br/>
<br/> The -c flag reverts files that are open in the specified changelist.
<br/>
<br/> The -C flag allows a user to specify the workspace that has the file
<br/> opened rather than defaulting to the current client workspace. When
<br/> this option is used, the '-k' flag is also enabled and the check for
<br/> matching user is disabled. The -C flag requires 'admin' access, which
<br/> is granted by 'p4 protect'.
<br/>
<br/>
</remarks>
</member>
<member name="T:Perforce.P4.ShelveFilesCmdFlags">
<summary>
Flags for the shelve command.
</summary>
</member>
<member name="F:Perforce.P4.ShelveFilesCmdFlags.None">
<summary>
No flags.
</summary>
</member>
<member name="F:Perforce.P4.ShelveFilesCmdFlags.Force">
<summary>
The -f (force) flag must be used with the -c or -i flag to overwrite
any existing shelved files in a pending changelist.
</summary>
</member>
<member name="F:Perforce.P4.ShelveFilesCmdFlags.Replace">
<summary>
The -r flag (used with -c or -i) enables you to replace all shelved
files in that changelist with the files opened in your own workspace
at that changelist number. Only the user and client workspace of the
pending changelist can replace its shelved files.
</summary>
</member>
<member name="F:Perforce.P4.ShelveFilesCmdFlags.Delete">
<summary>
The -d flag (used with -c) deletes the shelved files in the specified
changelist so that they can no longer be unshelved. By default, only
the user and client of the pending changelist can delete its shelved
files. A user with 'admin' access can delete shelved files by including
the -f flag to force the operation.
</summary>
</member>
<member name="F:Perforce.P4.ShelveFilesCmdFlags.ShelveUnchanged">
<summary>
The -a flag enables you to handle unchanged files similarly to some
client submit options, namely 'submitunchanged' and 'leaveunchanged'.
The default behavior of shelving all files corresponds to the
'submitunchanged' option. The 'leaveunchanged' option only shelves
changed files, and then leaves the files opened in the pending
changelist on the client.
</summary>
</member>
<member name="F:Perforce.P4.ShelveFilesCmdFlags.LeaveUnchanged">
<summary>
The -a flag enables you to handle unchanged files similarly to some
client submit options, namely 'submitunchanged' and 'leaveunchanged'.
The default behavior of shelving all files corresponds to the
'submitunchanged' option. The 'leaveunchanged' option only shelves
changed files, and then leaves the files opened in the pending
changelist on the client.
</summary>
</member>
<member name="F:Perforce.P4.ShelveFilesCmdFlags.Promote">
<summary>
The -p flag promotes a shelved change from an edge server to a
commitserver where it can be accessed by other edge servers
participating in the distributed configuration. Once a shelved
change has been promoted, all subsequent local modifications to
the shelf are also pushed to the commit server and remain until
the shelf is deleted. Once a shelf has been created, the combination
of flags '-p -c' will promote the shelf without modification.
</summary>
</member>
<member name="T:Perforce.P4.ShelveFilesCmdOptions">
<summary>
Shelve command options.
</summary>
</member>
<member name="M:Perforce.P4.ShelveFilesCmdOptions.#ctor(Perforce.P4.ShelveFilesCmdFlags,Perforce.P4.Changelist,System.Int32)">
<summary>
Shelve command options.
</summary>
<param name="flags"></param>
<param name="newChangelist"></param>
<param name="changelistId"></param>
<returns></returns>
<remarks>
<br/><b>p4 help shelve</b>
<br/>
<br/> shelve -- Store files from a pending changelist into the depot
<br/>
<br/> p4 shelve [-p] [files]
<br/> p4 shelve [-a option] [-p] -i [-f | -r]
<br/> p4 shelve [-a option] [-p] -r -c changelist#
<br/> p4 shelve [-a option] [-p] -c changelist# [-f] [file ...]
<br/> p4 shelve -d -c changelist# [-f] [file ...]
<br/>
<br/> 'p4 shelve' creates, modifies or deletes shelved files in a pending
<br/> changelist. Shelved files remain in the depot until they are deleted
<br/> (using 'p4 shelve -d') or replaced by subsequent shelve commands.
<br/> After 'p4 shelve', the user can revert the files and restore them
<br/> later using 'p4 unshelve'. Other users can 'p4 unshelve' the stored
<br/> files into their own workspaces.
<br/>
<br/> Files that have been shelved can be accessed by the 'p4 diff',
<br/> 'p4 diff2', 'p4 files' and 'p4 print' commands using the revision
<br/> specification '@=change', where 'change' is the pending changelist
<br/> number.
<br/>
<br/> By default, 'p4 shelve' creates a changelist, adds files from the
<br/> user's default changelist, then shelves those files in the depot.
<br/> The user is presented with a text changelist form displayed using
<br/> the editor configured using the $P4EDITOR environment variable.
<br/>
<br/> If a file pattern is specified, 'p4 shelve' shelves the files that
<br/> match the pattern.
<br/>
<br/> The -i flag reads the pending changelist specification with shelved
<br/> files from the standard input. The user's editor is not invoked.
<br/> To modify an existing changelist with shelved files, specify the
<br/> changelist number using the -c flag.
<br/>
<br/> The -c flag specifies the pending changelist that contains shelved
<br/> files to be created, deleted, or modified. Only the user and client
<br/> of the pending changelist can add or modify its shelved files. Any
<br/> files specified by the file pattern must already be opened in the
<br/> specified changelist; use 'p4 reopen' to move an opened file from
<br/> one changelist to another.
<br/>
<br/> The -f (force) flag must be used with the -c or -i flag to overwrite
<br/> any existing shelved files in a pending changelist.
<br/>
<br/> The -r flag (used with -c or -i) enables you to replace all shelved
<br/> files in that changelist with the files opened in your own workspace
<br/> at that changelist number. Previously shelved files will be deleted.
<br/> Only the user and client workspace of the pending changelist can
<br/> replace its shelved files.
<br/>
<br/> The -a flag enables you to handle unchanged files similarly to some
<br/> client submit options, namely 'submitunchanged' and 'leaveunchanged'.
<br/> The default behavior of shelving all files corresponds to the
<br/> 'submitunchanged' option. The 'leaveunchanged' option only shelves
<br/> changed files, and then leaves the files opened in the pending
<br/> changelist on the client.
<br/>
<br/> The -d flag (used with -c) deletes the shelved files in the specified
<br/> changelist so that they can no longer be unshelved. By default, only
<br/> the user and client of the pending changelist can delete its shelved
<br/> files. A user with 'admin' access can delete shelved files by including
<br/> the -f flag to force the operation.
<br/>
<br/> The -p flag promotes a shelved change from an edge server to a commit
<br/> server where it can be accessed by other edge servers participating
<br/> in the distributed configuration. Once a shelved change has been
<br/> promoted, all subsequent local modifications to the shelf are also
<br/> pushed to the commit server and remain until the shelf is deleted.
<br/> Once a shelf has been created, the combination of flags '-p -c' will
<br/> promote the shelf without modification unless '-f' or '-r' are also
<br/> used to update the shelved files before promotion.
<br/>
<br/> 'p4 shelve' is not supported for files with propagating attributes
<br/> from an edge server in a distributed environment.
<br/>
<br/>
</remarks>
</member>
<member name="T:Perforce.P4.SyncFilesCmdFlags">
<summary>
Flags for the sync command.
</summary>
</member>
<member name="F:Perforce.P4.SyncFilesCmdFlags.None">
<summary>
No flags.
</summary>
</member>
<member name="F:Perforce.P4.SyncFilesCmdFlags.Force">
<summary>
The -f flag forces resynchronization even if the client already
has the file, and overwriting any writable files. This flag doesn't
affect open files.
</summary>
</member>
<member name="F:Perforce.P4.SyncFilesCmdFlags.ProcessLikeLabel">
<summary>
The -L flag can be used with multiple file arguments that are in
full depot syntax and include a valid revision number. When this
flag is used the arguments are processed together by building an
internal table similar to a label. This file list processing is
significantly faster than having to call the internal query engine
for each individual file argument. However, the file argument syntax
is strict and the command will not run if an error is encountered.
</summary>
</member>
<member name="F:Perforce.P4.SyncFilesCmdFlags.Preview">
<summary>
The -n flag previews the operation without updating the workspace.
</summary>
</member>
<member name="F:Perforce.P4.SyncFilesCmdFlags.ServerOnly">
<summary>
The -k flag updates server metadata without syncing files. It is
intended to enable you to ensure that the server correctly reflects
the state of files in the workspace while avoiding a large data
transfer. Caution: an erroneous update can cause the server to
incorrectly reflect the state of the workspace.
</summary>
</member>
<member name="F:Perforce.P4.SyncFilesCmdFlags.PopulateClient">
<summary>
The -p flag populates the client workspace, but does not update the
server to reflect those updates. Any file that is already synced or
opened will be bypassed with a warning message. This option is very
useful for build clients or when publishing content without the
need to track the state of the client workspace.
</summary>
</member>
<member name="F:Perforce.P4.SyncFilesCmdFlags.Quiet">
<summary>
The -q flag suppresses normal output messages. Messages regarding
errors or exceptional conditions are not suppressed.
</summary>
</member>
<member name="F:Perforce.P4.SyncFilesCmdFlags.SafeMode">
<summary>
The -s flag adds a safety check before sending content to the client
workspace. This check uses MD5 digests to compare the content on the
clients workspace against content that was last synced. If the file
has been modified outside of Perforce's control then an error message
is displayed and the file is not overwritten. This check adds some
extra processing which will affect the performance of the operation.
</summary>
</member>
<member name="T:Perforce.P4.SyncFilesCmdOptions">
<summary>
Sync command options.
</summary>
</member>
<member name="M:Perforce.P4.SyncFilesCmdOptions.#ctor(Perforce.P4.SyncFilesCmdFlags,System.Int32)">
<summary>
Sync command options.
</summary>
<param name="flags"></param>
<param name="maxItems"></param>
<remarks>
<br/><b>p4 help sync</b>
<br/>
<br/> sync -- Synchronize the client with its view of the depot
<br/> flush -- synonym for 'sync -k'
<br/> update -- synonym for 'sync -s'
<br/>
<br/> p4 sync [-f -L -n -N -k -q -r] [-m max] [file[revRange] ...]
<br/> p4 sync [-L -n -N -q -s] [-m max] [file[revRange] ...]
<br/> p4 sync [-L -n -N -p -q] [-m max] [file[revRange] ...]
<br/> --parallel=threads=N[,batch=N][,batchsize=N][,min=N][,minsize=N]
<br/>
<br/> Sync updates the client workspace to reflect its current view (if
<br/> it has changed) and the current contents of the depot (if it has
<br/> changed). The client view maps client and depot file names and
<br/> locations.
<br/>
<br/> Sync adds files that are in the client view and have not been
<br/> retrieved before. Sync deletes previously retrieved files that
<br/> are no longer in the client view or have been deleted from the
<br/> depot. Sync updates files that are still in the client view and
<br/> have been updated in the depot.
<br/>
<br/> By default, sync affects all files in the client workspace. If file
<br/> arguments are given, sync limits its operation to those files.
<br/> The file arguments can contain wildcards.
<br/>
<br/> If the file argument includes a revision specifier, then the given
<br/> revision is retrieved. Normally, the head revision is retrieved.
<br/> See 'p4 help revisions' for help specifying revisions.
<br/>
<br/> If the file argument includes a revision range specification,
<br/> only files selected by the revision range are updated, and the
<br/> highest revision in the range is used.
<br/>
<br/> Normally, sync does not overwrite workspace files that the user has
<br/> manually made writable. Setting the 'clobber' option in the
<br/> client specification disables this safety check.
<br/>
<br/> The -f flag forces resynchronization even if the client already
<br/> has the file, and overwriting any writable files. This flag doesn't
<br/> affect open files.
<br/>
<br/> The -L flag can be used with multiple file arguments that are in
<br/> full depot syntax and include a valid revision number. When this
<br/> flag is used the arguments are processed together by building an
<br/> internal table similar to a label. This file list processing is
<br/> significantly faster than having to call the internal query engine
<br/> for each individual file argument. However, the file argument syntax
<br/> is strict and the command will not run if an error is encountered.
<br/>
<br/> The -n flag previews the operation without updating the workspace.
<br/>
<br/> The -N flag also previews the operation without updating the
<br/> workspace, but reports only a summary of the work the sync would do.
<br/>
<br/> The -k flag updates server metadata without syncing files. It is
<br/> intended to enable you to ensure that the server correctly reflects
<br/> the state of files in the workspace while avoiding a large data
<br/> transfer. Caution: an erroneous update can cause the server to
<br/> incorrectly reflect the state of the workspace.
<br/>
<br/> The -p flag populates the client workspace, but does not update the
<br/> server to reflect those updates. Any file that is already synced or
<br/> opened will be bypassed with a warning message. This option is very
<br/> useful for build clients or when publishing content without the
<br/> need to track the state of the client workspace.
<br/>
<br/> The -q flag suppresses normal output messages. Messages regarding
<br/> errors or exceptional conditions are not suppressed.
<br/>
<br/> The -r flag allows open files which are mapped to new locations
<br/> in the depot to be reopened in the new location. By default, open
<br/> workspace files remain associated with the depot files that they were
<br/> originally opened as.
<br/>
<br/> The -s flag adds a safety check before sending content to the client
<br/> workspace. This check uses MD5 digests to compare the content on the
<br/> clients workspace against content that was last synced. If the file
<br/> has been modified outside of Perforce's control then an error message
<br/> is displayed and the file is not overwritten. This check adds some
<br/> extra processing which will affect the performance of the operation.
<br/> Clients with 'allwrite' and 'noclobber' set do this check by default.
<br/>
<br/> The -m flag limits sync to the first 'max' number of files. This
<br/> option is useful in conjunction with tagged output and the '-n'
<br/> flag, to preview how many files will be synced without transferring
<br/> all the file data.
<br/>
<br/> The --parallel flag specifies options for parallel file transfer. If
<br/> your administrator has enabled parallel file transfer by setting the
<br/> net.parallel.max configurable, and if there are sufficient resources
<br/> across the system, a sync command may execute more rapidly by
<br/> transferring multiple files in parallel. Specify threads=N to request
<br/> files be sent concurrently, using N independent network connections.
<br/> The N threads grab work in batches; specify batch=N to control the
<br/> number of files in a batch, or batchsize=N to control the number of
<br/> bytes in a batch. A sync that is too small will not initiate parallel
<br/> file transfers; specify min=N to control the minimum number of files
<br/> in a parallel sync, or minsize=N to control the minimum number of
<br/> bytes in a parallel sync. Requesting progress indicators causes the
<br/> --parallel flag to be ignored.
<br/>
<br/>
</remarks>
</member>
<member name="T:Perforce.P4.UnlockFilesCmdFlags">
<summary>
Flags for the unlock command.
</summary>
</member>
<member name="F:Perforce.P4.UnlockFilesCmdFlags.None">
<summary>
No flags.
</summary>
</member>
<member name="F:Perforce.P4.UnlockFilesCmdFlags.Force">
<summary>
By default, files can be unlocked only by the changelist owner. The
-f flag enables you to unlock files in changelists owned by other
users. The -f flag requires 'admin' access, which is granted by 'p4
protect'.
</summary>
</member>
<member name="T:Perforce.P4.UnlockFilesCmdOptions">
<summary>
Unlock command options.
</summary>
</member>
<member name="M:Perforce.P4.UnlockFilesCmdOptions.#ctor(Perforce.P4.UnlockFilesCmdFlags,System.Int32)">
<summary>
Unlock command options.
</summary>
<param name="flags"></param>
<param name="changelistId"></param>
<returns></returns>
<remarks>
<br/><b>p4 help unlock</b>
<br/>
<br/> unlock -- Release a locked file, leaving it open
<br/>
<br/> p4 unlock [-c | -s changelist# | -x] [-f] [file ...]
<br/> p4 -c client unlock [-f] -r
<br/>
<br/> 'p4 unlock' releases locks on the specified files, which must be
<br/> open in the specified pending changelist. If you omit the changelist
<br/> number, the default changelist is assumed. If you omit the file name,
<br/> all locked files are unlocked.
<br/>
<br/> The -s flag unlocks files from a shelved changelist caused by an
<br/> aborted 'submit -e' operation. The -c flag applies to opened files
<br/> in a pending changelist locked by 'p4 lock' or by a failed submit
<br/> of a change that is not shelved.
<br/>
<br/> By default, files can be unlocked only by the changelist owner who
<br/> must also be the person who has the files locked. The -f flag
<br/> enables you to unlock files in changelists owned by other users.
<br/> The -f flag requires 'admin' access, which is granted by 'p4
<br/> protect'.
<br/>
<br/> The -x option unlocks files that are opened 'exclusive' but are
<br/> orphaned (see 'p4 opened -x'). This option only applies to a
<br/> distributed installation where global tracking of these file types
<br/> is necessary across servers.
<br/>
<br/> If a push command from a remote server to this server fails, files
<br/> can be left locked on this server, preventing other users from
<br/> submitting changes to those files. In this case, the user who issued
<br/> the push command can specify the -r flag with the name of the client
<br/> that was used on that remote server to unlock the files on this
<br/> server. An administrator can run 'unlock -f -r' as well.
<br/>
<br/>
</remarks>
</member>
<member name="T:Perforce.P4.UnshelveFilesCmdFlags">
<summary>
Flags for the unshelve command.
</summary>
</member>
<member name="F:Perforce.P4.UnshelveFilesCmdFlags.None">
<summary>
No flags.
</summary>
</member>
<member name="F:Perforce.P4.UnshelveFilesCmdFlags.Force">
<summary>
The -f flag forces the clobbering of any writeable but unopened files
that are being unshelved.
</summary>
</member>
<member name="F:Perforce.P4.UnshelveFilesCmdFlags.Preview">
<summary>
The -n flag previews the operation without changing any files or
metadata.
</summary>
</member>
<member name="T:Perforce.P4.UnshelveFilesCmdOptions">
<summary>
Unshelve command options.
</summary>
</member>
<member name="M:Perforce.P4.UnshelveFilesCmdOptions.#ctor(Perforce.P4.UnshelveFilesCmdFlags,System.Int32,System.Int32)">
<summary>
Unshelve command options.
</summary>
<param name="flags"></param>
<param name="changelistId"></param>
<param name="newChangelistId"></param>
<returns></returns>
<remarks>
<br/><b>p4 help unshelve</b>
<br/>
<br/> unshelve -- Restore shelved files from a pending change into a workspace
<br/>
<br/> p4 unshelve -s changelist# [options] [file ...]
<br/> Options: [-f -n] [-c changelist#] [-b branch|-S stream [-P parent]]
<br/>
<br/> 'p4 unshelve' retrieves shelved files from the specified pending
<br/> changelist, opens them in a pending changelist and copies them
<br/> to the invoking user's workspace. Unshelving files from a pending
<br/> changelist is restricted by the user's permissions on the files.
<br/> A successful unshelve operation places the shelved files on the
<br/> user's workspace with the same open action and pending integration
<br/> history as if it had originated from that user and client.
<br/>
<br/> Unshelving a file over an already opened file is permitted if both
<br/> shelved file and opened file are opened for 'edit'. In a distributed
<br/> environment, an additional requirement is that the shelve was created
<br/> on the same edge server. After unshelving, the workspace file is
<br/> flagged as unresolved, and 'p4 resolve' must be run to resolve the
<br/> differences between the shelved file and the workspace file.
<br/>
<br/> Unshelving a file opened for 'add' when the file already exists
<br/> in the depot will result in the file being opened for edit. After
<br/> unshelving, the workspace file is flagged as unresolved, and
<br/> 'p4 resolve' must be run to resolve the differences between the
<br/> shelved file and the depot file at the head revision. Note that
<br/> unshelving a file opened for 'add' over an already opened file is
<br/> not supported.
<br/>
<br/> The -s flag specifies the number of the pending changelist that
<br/> contains the shelved files.
<br/>
<br/> If a file pattern is specified, 'p4 unshelve' unshelves files that
<br/> match the pattern.
<br/>
<br/> The -b flag specifies a branch spec that the shelved files will be
<br/> mapped through prior to being unshelved, allowing files to be shelved
<br/> in one branch and unshelved in another. As with unshelving into an
<br/> open file, it may be necessary to run 'p4 resolve'. In a distributed
<br/> environment, an additional requirement is that the shelve was created
<br/> on the same edge server.
<br/>
<br/> The -S flag uses a generated branch view to map the shelved files
<br/> between the specified stream and its parent stream. The -P flag
<br/> can be used to generate the view using a parent stream other than
<br/> the actual parent.
<br/>
<br/> The -c flag specifies the changelist to which files are unshelved.
<br/> By default, 'p4 unshelve' opens shelved files in the default
<br/> changelist.
<br/>
<br/> The -f flag forces the clobbering of any writeable but unopened files
<br/> that are being unshelved.
<br/>
<br/> The -n flag previews the operation without changing any files or
<br/> metadata.
<br/>
<br/> 'p4 unshelve' is not supported for files with propagating attributes
<br/> from an edge server in a distributed environment.
<br/>
<br/>
</remarks>
</member>
<member name="T:Perforce.P4.CopyFilesCmdFlags">
<summary>
Flags for the copy command.
</summary>
</member>
<member name="F:Perforce.P4.CopyFilesCmdFlags.None">
<summary>
No flags.
</summary>
</member>
<member name="F:Perforce.P4.CopyFilesCmdFlags.Preview">
<summary>
The -n flag displays a preview of the copy, without actually doing
anything.
</summary>
</member>
<member name="F:Perforce.P4.CopyFilesCmdFlags.Virtual">
<summary>
The -v flag causes a 'virtual' copy that does not modify client
workspace files. After submitting a virtual integration, 'p4 sync'
can be used to update the workspace.
</summary>
</member>
<member name="F:Perforce.P4.CopyFilesCmdFlags.Reverse">
<summary>
The -r flag causes the direction of the copy to be reversed when
used with a branch (-b) or stream (-S) copy.
</summary>
</member>
<member name="F:Perforce.P4.CopyFilesCmdFlags.Force">
<summary>
The -F flag can be used with -S to force copying even though the
stream does not expect a copy to occur in the direction indicated.
Normally 'p4 copy' enforces the expected flow of change dictated
by the stream's spec. The 'p4 istat' command summarizes a stream's
expected flow of change.
</summary>
</member>
<member name="F:Perforce.P4.CopyFilesCmdFlags.SourceBranch">
<summary>
The -s flag can be used with -b to cause fromFile to be treated as
the source, and both sides of the user-defined branch view to be
treated as the target, per the branch view mapping. Optional toFile
arguments may be given to further restrict the scope of the target
file set. -r is ignored when -s is used.
</summary>
</member>
<member name="T:Perforce.P4.CopyFilesCmdOptions">
<summary>
Copy command options.
</summary>
</member>
<member name="M:Perforce.P4.CopyFilesCmdOptions.#ctor(Perforce.P4.CopyFilesCmdFlags,System.String,System.String,System.String,System.Int32,System.Int32)">
<summary>
Copy command options.
</summary>
<param name="flags"></param>
<param name="branchName"></param>
<param name="streamName"></param>
<param name="parentStream"></param>
<param name="changelistId"></param>
<param name="maxItems"></param>
<returns></returns>
<remarks>
<br/><b>p4 help copy</b>
<br/>
<br/> copy -- Copy one set of files to another
<br/>
<br/> p4 copy [options] fromFile[rev] toFile
<br/> p4 copy [options] -b branch [-r] [toFile[rev] ...]
<br/> p4 copy [options] -b branch -s fromFile[rev] [toFile ...]
<br/> p4 copy [options] -S stream [-P parent] [-F] [-r] [toFile[rev] ...]
<br/>
<br/> options: -c changelist# -f -n -v -m max -q
<br/>
<br/> 'p4 copy' copies one set of files (the 'source') into another (the
<br/> 'target').
<br/>
<br/> Using the client workspace as a staging area, 'p4 copy' makes the
<br/> target identical to the source by branching, replacing, or deleting
<br/> files. 'p4 submit' submits copied files to the depot. 'p4 revert'
<br/> can be used to revert copied files instead of submitting them. The
<br/> history of copied files can be shown with 'p4 filelog' or 'p4
<br/> integrated'.
<br/>
<br/> Target files that are already identical to the source, or that are
<br/> outside of the client view, are not affected by 'p4 copy'. Opened,
<br/> non-identical target files cause 'p4 copy' to exit with a warning.
<br/> When 'p4 copy' creates or modifies files in the workspace, it leaves
<br/> them read-only; 'p4 edit' can make them writable. Files opened by
<br/> 'p4 copy' do not need to be resolved.
<br/>
<br/> Source and target files (fromFile and toFile) can be specified on
<br/> the 'p4 copy' command line or through a branch view. On the command
<br/> line, fromFile is the source file set and toFile is the target file
<br/> set. With a branch view, one or more toFile arguments can be given
<br/> to limit the scope of the target file set.
<br/>
<br/> A revision specifier can be used to select the revision to copy; by
<br/> default, the head revision is copied. The revision specifier can be
<br/> used on fromFile, or on toFile, but not on both. When used on toFile,
<br/> it refers to source revisions, not to target revisions. A range may
<br/> not be used as a revision specifier. For revision syntax, see 'p4
<br/> help revisions'.
<br/>
<br/> The -S flag makes 'p4 copy' copy from a stream to its parent.
<br/> Use -r with -S to reverse the copy direction. Note that to submit
<br/> copied stream files, the current client must be switched to the
<br/> target stream, or to a virtual child stream of the target stream.
<br/> The -S flag causes 'p4 copy' to use a generated branch view that
<br/> maps the stream to its parent. -P can be used to generate the
<br/> branch view using a parent stream other than the stream's actual
<br/> parent. The -S flag also makes 'p4 copy' respect a stream's flow.
<br/>
<br/> The -F flag can be used with -S to force copying against a stream's
<br/> expected flow. It can also force -S to generate a branch view based
<br/> on a virtual stream; the mapping itself refers to the underlying
<br/> real stream.
<br/>
<br/> The -b flag makes 'p4 copy' use a user-defined branch view. (See
<br/> 'p4 help branch'.) The source is the left side of the branch view
<br/> and the target is the right side. With -r, the direction is reversed.
<br/>
<br/> The -s flag can be used with -b to cause fromFile to be treated as
<br/> the source, and both sides of the user-defined branch view to be
<br/> treated as the target, per the branch view mapping. Optional toFile
<br/> arguments may be given to further restrict the scope of the target
<br/> file set. -r is ignored when -s is used.
<br/>
<br/> The -c changelist# flag opens files in the designated (numbered)
<br/> pending changelist instead of the default changelist.
<br/>
<br/> The -f flag forces the creation of extra revisions in order to
<br/> explicitly record that files have been copied. Deleted source files
<br/> will be copied if they do not exist in the target, and files that are
<br/> already identical will be copied if they are not connected by existing
<br/> integration records.
<br/>
<br/> The -n flag displays a preview of the copy, without actually doing
<br/> anything.
<br/>
<br/> The -m flag limits the actions to the first 'max' number of files.
<br/>
<br/> The -q flag suppresses normal output messages. Messages regarding
<br/> errors or exceptional conditions are displayed.
<br/>
<br/> The -v flag causes a 'virtual' copy that does not modify client
<br/> workspace files. After submitting a virtual integration, 'p4 sync'
<br/> can be used to update the workspace.
<br/>
<br/> 'p4 copy' is not supported for files with propagating attributes
<br/> from an edge server in a distributed environment.
<br/>
<br/>
</remarks>
</member>
<member name="T:Perforce.P4.MergeFilesCmdFlags">
<summary>
Flags for the merge command.
</summary>
</member>
<member name="F:Perforce.P4.MergeFilesCmdFlags.None">
<summary>
No flags.
</summary>
</member>
<member name="F:Perforce.P4.MergeFilesCmdFlags.Preview">
<summary>
The -n flag displays a preview of the copy, without actually doing
anything.
</summary>
</member>
<member name="F:Perforce.P4.MergeFilesCmdFlags.Reverse">
<summary>
The -r flag causes the direction of the copy to be reversed when
used with a branch (-b) or stream (-S) copy.
</summary>
</member>
<member name="F:Perforce.P4.MergeFilesCmdFlags.Force">
<summary>
The -F flag can be used with -S to force copying even though the
stream does not expect a copy to occur in the direction indicated.
Normally 'p4 copy' enforces the expected flow of change dictated
by the stream's spec. The 'p4 istat' command summarizes a stream's
expected flow of change.
</summary>
</member>
<member name="F:Perforce.P4.MergeFilesCmdFlags.SourceBranch">
<summary>
The -s flag can be used with -b to cause fromFile to be treated as
the source, and both sides of the user-defined branch view to be
treated as the target, per the branch view mapping. Optional toFile
arguments may be given to further restrict the scope of the target
file set. -r is ignored when -s is used.
</summary>
</member>
<member name="T:Perforce.P4.MergeFilesCmdOptions">
<summary>
Merge command options.
</summary>
</member>
<!-- Badly formed XML comment ignored for member "M:Perforce.P4.MergeFilesCmdOptions.#ctor(Perforce.P4.MergeFilesCmdFlags,System.String,System.String,System.String,System.Int32,System.Int32)" -->
<member name="T:Perforce.P4.FixJobsCmdFlags">
<summary>
Flags for the fix command.
</summary>
</member>
<member name="F:Perforce.P4.FixJobsCmdFlags.None">
<summary>
No flags.
</summary>
</member>
<member name="F:Perforce.P4.FixJobsCmdFlags.Delete">
<summary>
The -d flag deletes the specified fixes. This operation does not
otherwise affect the specified changelist or jobs.
</summary>
</member>
<member name="T:Perforce.P4.FixJobsCmdOptions">
<summary>
Fix command options.
</summary>
</member>
<member name="M:Perforce.P4.FixJobsCmdOptions.#ctor(Perforce.P4.FixJobsCmdFlags,System.Int32,System.String)">
<summary>
Fix command options.
</summary>
<param name="flags"></param>
<param name="changelistId"></param>
<param name="status"></param>
<returns></returns>
<remarks>
<br/><b>p4 help fix</b>
<br/>
<br/> fix -- Mark jobs as being fixed by the specified changelist
<br/>
<br/> p4 fix [-d] [-s status] -c changelist# jobName ...
<br/>
<br/> 'p4 fix' marks each named job as being fixed by the changelist
<br/> number specified with -c. The changelist can be pending or
<br/> submitted and the jobs can be open or closed (fixed by another
<br/> changelist).
<br/>
<br/> If the changelist has already been submitted and the job is still
<br/> open, then 'p4 fix' marks the job closed. If the changelist has not
<br/> been submitted and the job is still open, the job is closed when the
<br/> changelist is submitted. If the job is already closed, it remains
<br/> closed.
<br/>
<br/> The -d flag deletes the specified fixes. This operation does not
<br/> otherwise affect the specified changelist or jobs.
<br/>
<br/> The -s flag uses the specified status instead of the default defined
<br/> in the job specification.
<br/>
<br/> The fix's status is reported by 'p4 fixes', and is related to the
<br/> job's status. Certain commands set the job's status to the fix's
<br/> status for each job associated with the change. When a job is fixed
<br/> by a submitted change, the job's status is set to match the fix
<br/> status. When a job is fixed by a pending change, the job's status
<br/> is set to match the fix status when the change is submitted. If the
<br/> fix's status is 'same', the job's status is left unchanged.
<br/>
<br/>
</remarks>
</member>
<member name="T:Perforce.P4.UserCmdFlags">
<summary>
Flags for the user command.
</summary>
</member>
<member name="F:Perforce.P4.UserCmdFlags.None">
<summary>
No flags.
</summary>
</member>
<member name="F:Perforce.P4.UserCmdFlags.Delete">
<summary>
The -d flag deletes the specified user (unless the user has files
open).
</summary>
</member>
<member name="F:Perforce.P4.UserCmdFlags.Output">
<summary>
The -o flag writes the user specification to the standard output.
The user's editor is not invoked.
</summary>
</member>
<member name="F:Perforce.P4.UserCmdFlags.Input">
<summary>
The -i flag reads a user specification from the standard input.
The user's editor is not invoked.
</summary>
</member>
<member name="F:Perforce.P4.UserCmdFlags.Force">
<summary>
The -f flag forces the creation, update or deletion of the specified
user, and enables you to change the Last Modified date. By default,
users can only delete or modify their own user specifications. The
-f flag requires 'super' access, which is granted by 'p4 protect'.
</summary>
</member>
<member name="T:Perforce.P4.UserCmdOptions">
<summary>
User command options.
</summary>
</member>
<member name="M:Perforce.P4.UserCmdOptions.#ctor(Perforce.P4.UserCmdFlags)">
<summary>
User command options.
</summary>
<param name="flags"></param>
<returns></returns>
<remarks>
<br/><b>p4 help user</b>
<br/>
<br/> user -- Create or edit a user specification
<br/>
<br/> p4 user [-f] [name]
<br/> p4 user -d [-f] name
<br/> p4 user -o [name]
<br/> p4 user -i [-f]
<br/>
<br/> Create a new user specification or edit an existing user specification.
<br/> The specification form is put into a temporary file and the editor
<br/> (configured by the environment variable $P4EDITOR) is invoked.
<br/>
<br/> Normally, a user specification is created automatically the first
<br/> time that the user issues any command that updates the depot. The
<br/> 'p4 user' command is typically used to edit the user's subscription
<br/> list for change review.
<br/>
<br/> The user specification form contains the following fields:
<br/>
<br/> User: The user name (read-only).
<br/>
<br/> Email: The user's email address (Default: user@client).
<br/>
<br/> Update: The date the specification was last modified (read-only).
<br/>
<br/> Access: The date that the user last issued a client command.
<br/>
<br/> FullName: The user's real name.
<br/>
<br/> JobView: Selects jobs that are displayed when the user creates
<br/> a changelist. These jobs can be closed automatically
<br/> when the user submits the changelist. For a description
<br/> of jobview syntax, see 'p4 help jobview'
<br/>
<br/> Reviews: The subscription list for change review. There is no
<br/> limit on the number of lines that this field can contain.
<br/> You can include the following wildcards:
<br/>
<br/> ... matches any characters including /
<br/> * matches any character except /
<br/>
<br/> Password: The user's password. See 'p4 help passwd'.
<br/>
<br/> Type: Must be 'service', operator, or 'standard'. Default is
<br/> 'standard'. Once set, the user type cannot be changed.
<br/>
<br/> AuthMethod: Must be 'perforce' or 'ldap'. Default is 'perforce'
<br/> Unless overridden by the 'auth.default.method'
<br/> configurable, see 'p4 help configurables'. AuthMethod
<br/> can only be changed when the -f flag has been provided.
<br/>
<br/> The -d flag deletes the specified user (unless the user has files
<br/> open).
<br/>
<br/> The -o flag writes the user specification to the standard output.
<br/> The user's editor is not invoked.
<br/>
<br/> The -i flag reads a user specification from the standard input.
<br/> The user's editor is not invoked.
<br/>
<br/> The -f flag forces the creation, update or deletion of the specified
<br/> user, and enables you to change the Last Modified date. By default,
<br/> users can only delete or modify their own user specifications. The
<br/> -f flag requires 'super' access, which is granted by 'p4 protect'.
<br/>
<br/>
</remarks>
</member>
<member name="T:Perforce.P4.UsersCmdFlags">
<summary>
Flags for the users command.
</summary>
</member>
<member name="F:Perforce.P4.UsersCmdFlags.None">
<summary>
No flags.
</summary>
</member>
<member name="F:Perforce.P4.UsersCmdFlags.IncludeAll">
<summary>
The -a flag includes service and operator users in the output.
</summary>
</member>
<member name="F:Perforce.P4.UsersCmdFlags.LongForm">
<summary>
The -l flag includes additional information in the output. The -l
flag requires 'super' access, which is granted by 'p4 protect'.
</summary>
</member>
<member name="T:Perforce.P4.UsersCmdOptions">
<summary>
Users command options
</summary>
</member>
<member name="M:Perforce.P4.UsersCmdOptions.#ctor(Perforce.P4.UsersCmdFlags,System.Int32)">
<summary>
Users command options.
</summary>
<param name="flags"></param>
<param name="maxItems"></param>
<returns></returns>
<remarks>
<br/><b>p4 help users</b>
<br/>
<br/> users -- List Perforce users
<br/>
<br/> p4 users [-l -a -r -c] [-m max] [user ...]
<br/>
<br/> Lists all Perforce users or users that match the 'user' argument.
<br/> The report includes the last time that each user accessed the system.
<br/>
<br/> The -m max flag limits output to the first 'max' number of users.
<br/>
<br/> The -a flag includes service and operator users in the output.
<br/>
<br/> The -l flag includes additional information in the output. The -l
<br/> flag requires 'super' access, which is granted by 'p4 protect'.
<br/>
<br/> The -r and -c flags are only allowed on replica servers. When
<br/> -r is given only users who have used a replica are reported and
<br/> when -c is given only the user information from the central server
<br/> is reported. Otherwise on a replica server, the user list will
<br/> be slightly different from the master server as the user access times
<br/> will reflect replica usage or master usage whichever is newer.
<br/>
<br/>
</remarks>
</member>
<member name="T:Perforce.P4.ClientCmdFlags">
<summary>
Flags for the client command.
</summary>
</member>
<member name="F:Perforce.P4.ClientCmdFlags.None">
<summary>
No flags.
</summary>
</member>
<member name="F:Perforce.P4.ClientCmdFlags.Delete">
<summary>
The -d flag deletes the specified spec, as long as the client
workspace has no opened files or pending changes. (See 'p4 help
opened'.) The -f flag forces the delete.
</summary>
</member>
<member name="F:Perforce.P4.ClientCmdFlags.Output">
<summary>
The -o flag writes the named client spec to the standard output.
The user's editor is not invoked.
</summary>
</member>
<member name="F:Perforce.P4.ClientCmdFlags.Input">
<summary>
The -i flag reads a client spec from the standard input. The
user's editor is not invoked.
</summary>
</member>
<member name="F:Perforce.P4.ClientCmdFlags.Force">
<summary>
The -f flag can force the updating of locked clients; normally
locked clients can only be modified by their owner. -f also allows
the last modified date to be set. The -f flag requires 'admin'
access granted by 'p4 protect'.
</summary>
</member>
<member name="F:Perforce.P4.ClientCmdFlags.Switch">
<summary>
The -s flag is used to switch an existing client spec's view without
invoking the editor. It can be used with -S to switch to a stream
view, or with -t to switch to a view defined in another client spec.
Switching views is not allowed in a client that has opened files.
The -f flag can be used with -s to force switching with opened files.
View switching has no effect on files in a client workspace until
'p4 sync' is run.
</summary>
</member>
<member name="T:Perforce.P4.ClientCmdOptions">
<summary>
Client command options
</summary>
</member>
<member name="M:Perforce.P4.ClientCmdOptions.#ctor(Perforce.P4.ClientCmdFlags)">
<summary>
Client command options.
</summary>
<param name="flags"></param>
<returns></returns>
<remarks>
<br/><b>p4 help client</b>
<br/>
<br/> client -- Create or edit a client workspace specification and its view
<br/> workspace -- Synonym for 'client'
<br/>
<br/> p4 client [-f] [-t template] [name]
<br/> p4 client -d [-f [-Fs]] name
<br/> p4 client -o [-t template] [name]
<br/> p4 client -S stream [[-c change] -o] [name]
<br/> p4 client -s [-f] -S stream [name]
<br/> p4 client -s [-f] -t template [name]
<br/> p4 client -i [-f]
<br/>
<br/> Creates a new client specification ('spec') or edits an existing
<br/> spec. A client spec is a named mapping of depot files to workspace
<br/> files.
<br/>
<br/> The 'p4 client' command puts the client spec into a temporary file
<br/> and invokes the editor configured by the environment variable
<br/> $P4EDITOR. For new workspaces, the client name defaults to the
<br/> $P4CLIENT environment variable, if set, or to the current host name.
<br/> Saving the file creates or modifies the client spec.
<br/>
<br/> The client spec contains the following fields:
<br/>
<br/> Client: The client name.
<br/>
<br/> Host: If set, restricts access to the named host.
<br/> If