<?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)"> <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*'. -E makes <br/> the matching case-insensitive. <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 <br/> that the user be an operator or have 'super' access granted by <br/> '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: 'local', 'stream', 'remote', 'spec', 'archive', <br/> 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/> (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: 'local', 'stream', 'remote', 'spec', 'archive', <br/> 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/> (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: 'local', 'stream', 'remote', 'spec', 'archive', <br/> 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/> (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: 'local', 'stream', 'remote', 'spec', 'archive', <br/> 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/> (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: 'local', 'stream', 'remote', 'spec', 'archive', <br/> 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/> (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: 'local', 'stream', 'remote', 'spec', 'archive', <br/> 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/> (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] <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/> 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' 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] [[[-i] user | group] | [-v [group]]] <br/> <br/> List all user groups defined in the server. 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 -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 the specified group. <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) change <br/> is accessible to its owner. Public changes are accessible to all <br/> users. This setting affects the output of the 'p4 change', <br/> 'p4 changes', and 'p4 describe' commands. <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) change <br/> is accessible to its owner. Public changes are accessible to all <br/> users. This setting affects the output of the 'p4 change', <br/> 'p4 changes', and 'p4 describe' commands. <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) change <br/> is accessible to its owner. Public changes are accessible to all <br/> users. This setting affects the output of the 'p4 change', <br/> 'p4 changes', and 'p4 describe' commands. <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) change <br/> is accessible to its owner. Public changes are accessible to all <br/> users. This setting affects the output of the 'p4 change', <br/> 'p4 changes', and 'p4 describe' commands. <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) change <br/> is accessible to its owner. Public changes are accessible to all <br/> users. This setting affects the output of the 'p4 change', <br/> 'p4 changes', and 'p4 describe' commands. <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) change <br/> is accessible to its owner. Public changes are accessible to all <br/> users. This setting affects the output of the 'p4 change', <br/> 'p4 changes', and 'p4 describe' commands. <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) change <br/> is accessible to its owner. Public changes are accessible to all <br/> users. This setting affects the output of the 'p4 change', <br/> 'p4 changes', and 'p4 describe' commands. <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) change <br/> is accessible to its owner. Public changes are accessible to all <br/> users. This setting affects the output of the 'p4 change', <br/> 'p4 changes', and 'p4 describe' commands. <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 pending, shelved or <br/> submitted changelists. <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) change <br/> is accessible to its owner. Public changes are accessible to all <br/> users. This setting affects the output of the 'p4 change', <br/> 'p4 changes', and 'p4 describe' commands. <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. <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 behaviour. <br/> <br/> submitunchanged All open files are submitted (default). <br/> <br/> revertunchanged Files that have content or type changes <br/> are submitted. Unchanged files are <br/> reverted. <br/> <br/> leaveunchanged Files that have content or type changes <br/> are submitted. Unchanged files are moved <br/> 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/> 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, it is ignored. Using -S sets the client's <br/> Stream field. The special syntax '-S //a/stream@changelist' can be <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/> </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. <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 behaviour. <br/> <br/> submitunchanged All open files are submitted (default). <br/> <br/> revertunchanged Files that have content or type changes <br/> are submitted. Unchanged files are <br/> reverted. <br/> <br/> leaveunchanged Files that have content or type changes <br/> are submitted. Unchanged files are moved <br/> 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/> 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, it is ignored. Using -S sets the client's <br/> Stream field. The special syntax '-S //a/stream@changelist' can be <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/> </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. <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 behaviour. <br/> <br/> submitunchanged All open files are submitted (default). <br/> <br/> revertunchanged Files that have content or type changes <br/> are submitted. Unchanged files are <br/> reverted. <br/> <br/> leaveunchanged Files that have content or type changes <br/> are submitted. Unchanged files are moved <br/> 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/> 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, it is ignored. Using -S sets the client's <br/> Stream field. The special syntax '-S //a/stream@changelist' can be <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/> </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. <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 behaviour. <br/> <br/> submitunchanged All open files are submitted (default). <br/> <br/> revertunchanged Files that have content or type changes <br/> are submitted. Unchanged files are <br/> reverted. <br/> <br/> leaveunchanged Files that have content or type changes <br/> are submitted. Unchanged files are moved <br/> 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/> 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, it is ignored. Using -S sets the client's <br/> Stream field. The special syntax '-S //a/stream@changelist' can be <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/> </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. <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 behaviour. <br/> <br/> submitunchanged All open files are submitted (default). <br/> <br/> revertunchanged Files that have content or type changes <br/> are submitted. Unchanged files are <br/> reverted. <br/> <br/> leaveunchanged Files that have content or type changes <br/> are submitted. Unchanged files are moved <br/> 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/> 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, it is ignored. Using -S sets the client's <br/> Stream field. The special syntax '-S //a/stream@changelist' can be <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/> </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*'. -E makes <br/> the matching case-insensitive. <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/> </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. <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 behaviour. <br/> <br/> submitunchanged All open files are submitted (default). <br/> <br/> revertunchanged Files that have content or type changes <br/> are submitted. Unchanged files are <br/> reverted. <br/> <br/> leaveunchanged Files that have content or type changes <br/> are submitted. Unchanged files are moved <br/> 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/> 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, it is ignored. Using -S sets the client's <br/> Stream field. The special syntax '-S //a/stream@changelist' can be <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/> </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 <br/> unload' for more information about the unload depot). <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/> </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> <member name="M:Perforce.P4.Repository.GetFileMetaData(Perforce.P4.Options,Perforce.P4.FileSpec[])"> <summary> Use the p4 fstat command to get the file metadata for the files matching the FileSpec. </summary> <param name="filespecs"></param> <param name="options"></param> <returns></returns> <remarks> <br/><b>p4 help fstat</b> <br/> <br/> fstat -- Dump file info <br/> <br/> p4 fstat [-F filter -L -T fields -m max -r] [-c | -e changelist#] <br/> [-Ox -Rx -Sx] file[rev] ... <br/> <br/> Fstat lists information about files, one line per file. Fstat is <br/> intended for use in Perforce API applications, where the output can <br/> be accessed as variables, but its output is also suitable for parsing <br/> from the client command output in scripts. <br/> <br/> The fields that fstat displays are: <br/> <br/> attr-<name> -- attribute value for <name> <br/> attrProp-<name> -- set if attribute <name> is propagating <br/> clientFile -- local path (host or Perforce syntax) <br/> depotFile -- name in depot <br/> movedFile -- name in depot of moved to/from file <br/> path -- local path (host syntax) <br/> isMapped -- set if mapped client file is synced <br/> shelved -- set if file is shelved <br/> headAction -- action at head rev, if in depot <br/> headChange -- head rev changelist#, if in depot <br/> headRev -- head rev #, if in depot <br/> headType -- head rev type, if in depot <br/> headCharset -- head charset, for unicode type <br/> headTime -- head rev changelist time, if in depot <br/> headModTime -- head rev mod time, if in depot <br/> movedRev -- head rev # of moved file <br/> haveRev -- rev had on client, if on client <br/> desc -- change description <br/> digest -- MD5 digest (fingerprint) <br/> fileSize -- file size <br/> action -- open action, if opened <br/> type -- open type, if opened <br/> charset -- open charset, for unicode type <br/> actionOwner -- user who opened file, if opened <br/> change -- open changelist#, if opened <br/> resolved -- resolved integration records <br/> unresolved -- unresolved integration records <br/> reresolvable -- reresolvable integration records <br/> otherOpen -- set if someone else has it open <br/> otherOpen# -- list of user@client with file opened <br/> otherLock -- set if someone else has it locked <br/> otherLock# -- user@client with file locked <br/> otherAction# -- open action, if opened by someone else <br/> otherChange# -- changelist, if opened by someone else <br/> openattr-<name> -- attribute value for <name> <br/> openattrProp-<name> -- set if attribute <name> is propagating <br/> ourLock -- set if this user/client has it locked <br/> resolveAction# -- pending integration record action <br/> resolveBaseFile# -- pending integration base file <br/> resolveBaseRev# -- pending integration base rev <br/> resolveFromFile# -- pending integration from file <br/> resolveStartFromRev# -- pending integration from start rev <br/> resolveEndFromRev# -- pending integration from end rev <br/> totalFileCount -- total no. of files, if sorted <br/> <br/> The -A <pattern> flag restricts displayed attributes to those <br/> that match 'pattern'. <br/> <br/> The -F flag lists only files satisfying the filter expression. This <br/> filter syntax is similar to the one used for 'jobs -e jobview' and is <br/> used to evaluate the contents of the fields in the preceding list. <br/> Filtering is case-sensitive. <br/> <br/> Example: -Ol -F "fileSize > 1000000 & headType=text" <br/> <br/> Note: filtering is not optimized with indexes for performance. <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 -T fields flag returns only the specified fields. The field names <br/> can be specified using a comma- or space-delimited list. <br/> <br/> Example: -Ol -T "depotFile, fileSize" <br/> <br/> The -m max flag limits output to the specified number of files. <br/> <br/> The -r flag sorts the output in reverse order. <br/> <br/> The -c changelist# flag displays files modified after the specified <br/> changelist was submitted. This operation is much faster than using <br/> a revision range on the affected files. <br/> <br/> The -e changelist# flag lists files modified by the specified <br/> changelist. When used with the -Ro flag, only pending changes are <br/> considered, to ensure that files opened for add are included. This <br/> option also displays the change description. <br/> <br/> The -O options modify the output as follows: <br/> <br/> -Oa output attributes set by 'p4 attribute'. <br/> <br/> -Od output the digest of the attribute. <br/> <br/> -Oe output attribute values encoded as hex <br/> <br/> -Of output all revisions for the given files (this <br/> option suppresses other* and resolve* fields) <br/> <br/> -Ol output a fileSize and digest field for each revision <br/> (this may be expensive to compute) <br/> <br/> -Op output the local file path in both Perforce syntax <br/> (//client/) as 'clientFile' and host form as 'path' <br/> <br/> -Or output pending integration record information for <br/> files opened on the current client, or if used with <br/> '-e <change> -Rs', on the shelved change <br/> <br/> -Os exclude client-related data from output <br/> <br/> The -R option limits output to specific files: <br/> <br/> -Rc files mapped in the client view <br/> -Rh files synced to the client workspace <br/> -Rn files opened not at the head revision <br/> -Ro files opened <br/> -Rr files opened that have been resolved <br/> -Rs files shelved (requires -e) <br/> -Ru files opened that need resolving <br/> <br/> The -S option changes the order of output: <br/> <br/> -St sort by filetype <br/> -Sd sort by date <br/> -Sr sort by head revision <br/> -Sh sort by have revision <br/> -Ss sort by filesize <br/> <br/> The -U flag displays information about unload files in the unload <br/> depot (see 'p4 help unload'). <br/> <br/> For compatibility, the following flags are also supported: <br/> -C (-Rc) -H (-Rh) -W (-Ro) -P (-Op) -l (-Ol) -s (-Os). <br/> <br/> </remarks> <example> To get FileMetaData for //depot/ReadMe.txt: <code> FileSpec fs = new FileSpec(new DepotPath("//depot/MyCode/ReadMe.txt"), null); GetFileMetaDataCmdOptions opts = new GetFileMetaDataCmdOptions(GetFileMetadataCmdFlags.None, null, null, 0, null, null, null); IList<FileMetaData> target = Repository.GetFileMetaData(opts, fs); </code> To get FileMetaData for files in the depot that need resolving: <code> FileSpec fs = new FileSpec(new DepotPath("//..."), null); GetFileMetaDataCmdOptions opts = new GetFileMetaDataCmdOptions(GetFileMetadataCmdFlags.NeedsResolve, null, null, 0, null, null, null); IList<FileMetaData> target = Repository.GetFileMetaData(opts, fs); </code> To get FileMetaData for files in the depot that are over a specific file size and of file type, text: <code> FileSpec fs = new FileSpec(new DepotPath("//..."), null); GetFileMetaDataCmdOptions opts = new GetFileMetaDataCmdOptions(GetFileMetadataCmdFlags.None, "fileSize > 1000000 & headType=text", null, 0, null, null, null); IList<FileMetaData> target = Repository.GetFileMetaData(opts, fs); </code> To get FileMetaData for files in the depot that have been modified at or after changelist 20345 and are mapped to the client view: <code> FileSpec fs = new FileSpec(new DepotPath("//..."), null); GetFileMetaDataCmdOptions opts = new GetFileMetaDataCmdOptions(GetFileMetadataCmdFlags.ClientMapped, null, null, 20345, null, null, null); IList<FileMetaData> target = Repository.GetFileMetaData(opts, fs); </code> To get FileMetaData for files in the depot including attributes which match the pattern "tested": <code> FileSpec fs = new FileSpec(new DepotPath("//..."), null); GetFileMetaDataCmdOptions opts = new GetFileMetaDataCmdOptions(GetFileMetadataCmdFlags.Attributes, null, null, 0, null, null, "tested"); IList<FileMetaData> target = Repository.GetFileMetaData(opts, fs); </code> </example> <seealso cref="T:Perforce.P4.GetFileMetadataCmdFlags"/> </member> <member name="M:Perforce.P4.Repository.GetFileMetaData(System.Collections.Generic.IList{Perforce.P4.FileSpec},Perforce.P4.Options)"> <summary> Use the p4 fstat command to get the file metadata for the files matching the FileSpec. </summary> <param name="filespecs"></param> <param name="options"></param> <returns></returns> <remarks> <br/><b>p4 help fstat</b> <br/> <br/> fstat -- Dump file info <br/> <br/> p4 fstat [-F filter -L -T fields -m max -r] [-c | -e changelist#] <br/> [-Ox -Rx -Sx] file[rev] ... <br/> <br/> Fstat lists information about files, one line per file. Fstat is <br/> intended for use in Perforce API applications, where the output can <br/> be accessed as variables, but its output is also suitable for parsing <br/> from the client command output in scripts. <br/> <br/> The fields that fstat displays are: <br/> <br/> attr-<name> -- attribute value for <name> <br/> attrProp-<name> -- set if attribute <name> is propagating <br/> clientFile -- local path (host or Perforce syntax) <br/> depotFile -- name in depot <br/> movedFile -- name in depot of moved to/from file <br/> path -- local path (host syntax) <br/> isMapped -- set if mapped client file is synced <br/> shelved -- set if file is shelved <br/> headAction -- action at head rev, if in depot <br/> headChange -- head rev changelist#, if in depot <br/> headRev -- head rev #, if in depot <br/> headType -- head rev type, if in depot <br/> headCharset -- head charset, for unicode type <br/> headTime -- head rev changelist time, if in depot <br/> headModTime -- head rev mod time, if in depot <br/> movedRev -- head rev # of moved file <br/> haveRev -- rev had on client, if on client <br/> desc -- change description <br/> digest -- MD5 digest (fingerprint) <br/> fileSize -- file size <br/> action -- open action, if opened <br/> type -- open type, if opened <br/> charset -- open charset, for unicode type <br/> actionOwner -- user who opened file, if opened <br/> change -- open changelist#, if opened <br/> resolved -- resolved integration records <br/> unresolved -- unresolved integration records <br/> reresolvable -- reresolvable integration records <br/> otherOpen -- set if someone else has it open <br/> otherOpen# -- list of user@client with file opened <br/> otherLock -- set if someone else has it locked <br/> otherLock# -- user@client with file locked <br/> otherAction# -- open action, if opened by someone else <br/> otherChange# -- changelist, if opened by someone else <br/> openattr-<name> -- attribute value for <name> <br/> openattrProp-<name> -- set if attribute <name> is propagating <br/> ourLock -- set if this user/client has it locked <br/> resolveAction# -- pending integration record action <br/> resolveBaseFile# -- pending integration base file <br/> resolveBaseRev# -- pending integration base rev <br/> resolveFromFile# -- pending integration from file <br/> resolveStartFromRev# -- pending integration from start rev <br/> resolveEndFromRev# -- pending integration from end rev <br/> totalFileCount -- total no. of files, if sorted <br/> <br/> The -A <pattern> flag restricts displayed attributes to those <br/> that match 'pattern'. <br/> <br/> The -F flag lists only files satisfying the filter expression. This <br/> filter syntax is similar to the one used for 'jobs -e jobview' and is <br/> used to evaluate the contents of the fields in the preceding list. <br/> Filtering is case-sensitive. <br/> <br/> Example: -Ol -F "fileSize > 1000000 & headType=text" <br/> <br/> Note: filtering is not optimized with indexes for performance. <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 -T fields flag returns only the specified fields. The field names <br/> can be specified using a comma- or space-delimited list. <br/> <br/> Example: -Ol -T "depotFile, fileSize" <br/> <br/> The -m max flag limits output to the specified number of files. <br/> <br/> The -r flag sorts the output in reverse order. <br/> <br/> The -c changelist# flag displays files modified after the specified <br/> changelist was submitted. This operation is much faster than using <br/> a revision range on the affected files. <br/> <br/> The -e changelist# flag lists files modified by the specified <br/> changelist. When used with the -Ro flag, only pending changes are <br/> considered, to ensure that files opened for add are included. This <br/> option also displays the change description. <br/> <br/> The -O options modify the output as follows: <br/> <br/> -Oa output attributes set by 'p4 attribute'. <br/> <br/> -Od output the digest of the attribute. <br/> <br/> -Oe output attribute values encoded as hex <br/> <br/> -Of output all revisions for the given files (this <br/> option suppresses other* and resolve* fields) <br/> <br/> -Ol output a fileSize and digest field for each revision <br/> (this may be expensive to compute) <br/> <br/> -Op output the local file path in both Perforce syntax <br/> (//client/) as 'clientFile' and host form as 'path' <br/> <br/> -Or output pending integration record information for <br/> files opened on the current client, or if used with <br/> '-e <change> -Rs', on the shelved change <br/> <br/> -Os exclude client-related data from output <br/> <br/> The -R option limits output to specific files: <br/> <br/> -Rc files mapped in the client view <br/> -Rh files synced to the client workspace <br/> -Rn files opened not at the head revision <br/> -Ro files opened <br/> -Rr files opened that have been resolved <br/> -Rs files shelved (requires -e) <br/> -Ru files opened that need resolving <br/> <br/> The -S option changes the order of output: <br/> <br/> -St sort by filetype <br/> -Sd sort by date <br/> -Sr sort by head revision <br/> -Sh sort by have revision <br/> -Ss sort by filesize <br/> <br/> The -U flag displays information about unload files in the unload <br/> depot (see 'p4 help unload'). <br/> <br/> For compatibility, the following flags are also supported: <br/> -C (-Rc) -H (-Rh) -W (-Ro) -P (-Op) -l (-Ol) -s (-Os). <br/> <br/> </remarks> <example> To get FileMetaData for //depot/ReadMe.txt: <code> FileSpec fs = new FileSpec(new DepotPath("//depot/MyCode/ReadMe.txt"), null); IList<FileSpec> lfs = new List<FileSpec>(); lfs.Add(fs); GetFileMetaDataCmdOptions opts = new GetFileMetaDataCmdOptions(GetFileMetadataCmdFlags.None, null, null, 0, null, null, null); IList<FileMetaData> target = Repository.GetFileMetaData(lfs, opts); </code> To get FileMetaData for files in the depot that need resolving: <code> FileSpec fs = new FileSpec(new DepotPath("//..."), null); IList<FileSpec> lfs = new List<FileSpec>(); lfs.Add(fs); GetFileMetaDataCmdOptions opts = new GetFileMetaDataCmdOptions(GetFileMetadataCmdFlags.NeedsResolve, null, null, 0, null, null, null); IList<FileMetaData> target = Repository.GetFileMetaData(lfs, opts); </code> To get FileMetaData for files in the depot that are over a specific file size and of file type, text: <code> FileSpec fs = new FileSpec(new DepotPath("//..."), null); IList<FileSpec> lfs = new List<FileSpec>(); lfs.Add(fs); GetFileMetaDataCmdOptions opts = new GetFileMetaDataCmdOptions(GetFileMetadataCmdFlags.None, "fileSize > 1000000 & headType=text", null, 0, null, null, null); IList<FileMetaData> target = Repository.GetFileMetaData(lfs, opts); </code> To get FileMetaData for files in the depot that have been modified at or after changelist 20345 and are mapped to the client view: <code> FileSpec fs = new FileSpec(new DepotPath("//..."), null); IList<FileSpec> lfs = new List<FileSpec>(); lfs.Add(fs); GetFileMetaDataCmdOptions opts = new GetFileMetaDataCmdOptions(GetFileMetadataCmdFlags.ClientMapped, null, null, 20345, null, null, null); IList<FileMetaData> target = Repository.GetFileMetaData(lfs, opts); </code> To get FileMetaData for files in the depot including attributes which match the pattern "tested": <code> FileSpec fs = new FileSpec(new DepotPath("//..."), null); IList<FileSpec> lfs = new List<FileSpec>(); lfs.Add(fs); GetFileMetaDataCmdOptions opts = new GetFileMetaDataCmdOptions(GetFileMetadataCmdFlags.Attributes, null, null, 0, null, null, "tested"); IList<FileMetaData> target = Repository.GetFileMetaData(lfs, opts); </code> </example> <seealso cref="T:Perforce.P4.GetFileMetadataCmdFlags"/> </member> <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 -o localFile -q] file[revRange] ... <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 -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/> </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 -o localFile -q] file[revRange] ... <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 -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/> </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 -o localFile -q] file[revRange] ... <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 -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/> </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 -o localFile -q] file[revRange] ... <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 -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/> </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 maxRevs -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 maxRevs displays at most 'maxRevs' revisions per file of <br/> the file[rev] argument specified. <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 maxRevs -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 maxRevs displays at most 'maxRevs' revisions per file of <br/> the file[rev] argument specified. <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 [-aciIq -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. <br/> <br/> The -q flag suppresses the one-line header that is displayed by <br/> default for each file. <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 -n] -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/> To list the file revisions tagged with a label, use 'p4 files <br/> @label'. <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 display 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/> </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 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 changelist#] [file ...] <br/> <br/> 'p4 reviews' lists all users who have subscribed to review the <br/> specified files, the files in the specified changelist, or all files <br/> (the default). To subscribe to review files, issue the 'p4 user' <br/> command and edit 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 definitions (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, trigger, 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/> (include 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, and external archive integration. <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, 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. 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. <br/> <br/> Each trigger line contains a trigger name, a trigger type, a depot <br/> file path pattern 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 'server address' can be optionally passed to the <br/> client script by appending %serverAddress% to the <br/> 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 an edge-* or change-* <br/> trigger 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. <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/> %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/> 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, command, and auth triggers, it <br/> is the file content for the archive trigger. When triggers.io <br/> is set to 1, (except for archive triggers,) stdin is a textual <br/> dictionary containing connection information that the trigger. <br/> must read. <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 depot 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/> 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', and 'unicode' are reserved names: do not use them <br/> 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/> Counters can be assigned textual values as well as numeric ones, <br/> despite the name 'counter'. <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/> 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. Prohibits <br/> 'p4 labelsync'. For a loaded label, prevents <br/> '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/> 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. <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/> 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 names that match the <br/> the nameFilter pattern, for example: -e 'svr-dev-rel*'. -E makes <br/> the matching case-insensitive. <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/> </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. 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/> identfier, 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/> 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/> 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 may <br/> modify it. <br/> <br/> allsubmit * Indicates whether all users or only the <br/> ownersubmit of the stream may submit changes to the <br/> stream path. <br/> <br/> toparent * Indicates whether integration from the <br/> notoparent stream to its parent is expected to occur. <br/> <br/> fromparent * Indicates whether integration to the stream <br/> nofromparent from its parent is expected to occur. <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. <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/> 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/> 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/> 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/> 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/> 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/> 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/> 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 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. This status is reported by 'p4 fixes'. <br/> The 'p4 fix' and 'p4 change' (of a submitted changelist) and 'p4 submit' <br/> (of a pending changelist) commands set the job's status to the fix's <br/> status for each job associated with the change. If the fix's status <br/> 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 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. This status is reported by 'p4 fixes'. <br/> The 'p4 fix' and 'p4 change' (of a submitted changelist) and 'p4 submit' <br/> (of a pending changelist) commands set the job's status to the fix's <br/> status for each job associated with the change. If the fix's status <br/> 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 -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/> 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 -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 -v flag enables you to delete files that are not synced to the <br/> client workspace. <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/> </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 choosen <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/> </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# -d -f -h -i -o -n -m max -t -v <br/> -D<flags> -R<flags> <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 stream's branch view. (See <br/> 'p4 help stream'.) The source is the stream itself, and the target is <br/> the stream's parent. With -r, the direction is reversed. -P can be <br/> used to specify a parent stream other than the stream's actual parent. <br/> Note that to submit integrated stream files, the current client must <br/> be dedicated to the target stream. (See 'p4 help client'.) <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. Moved source files may <br/> cause target files to be scheduled for filename resolves. <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 -i flag enables merging between files that have no prior <br/> integration history. By default, 'p4 integrate' requires a prior <br/> integration in order to identify a base for merging. The -i flag <br/> allows the integration, and schedules the target file to be resolved <br/> using the first source revision as the merge base. <br/> <br/> The -o flag causes more merge information to be output. For each <br/> target file scheduled to be resolved, the base file revision and the <br/> source file revision are shown. (After running 'p4 integrate', the <br/> same information is available from 'p4 resolve -o'.) <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 -D flags modify the way deleted files are treated: <br/> <br/> -Dt If the target file has been deleted and the source <br/> file has changed, re-branch the source file on top <br/> of the target file instead of scheduling a resolve. <br/> <br/> -Ds If the source file has been deleted and the target <br/> file has changed, delete the target file instead of <br/> scheduling a resolve. <br/> <br/> -Di If the source file has been deleted and re-added, <br/> probe revisions that precede the deletion to find <br/> unintegrated revisions. By default, 'p4 integrate' <br/> starts probing at the last re-added revision. <br/> <br/> The -d flag is a shorthand for all -D flags used together. <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 -t flag propagates source filetypes instead of scheduling <br/> filetype conflicts to be resolved. <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/> 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/> </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# -d -f -h -i -o -n -m max -t -v <br/> -D<flags> -R<flags> <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 stream's branch view. (See <br/> 'p4 help stream'.) The source is the stream itself, and the target is <br/> the stream's parent. With -r, the direction is reversed. -P can be <br/> used to specify a parent stream other than the stream's actual parent. <br/> Note that to submit integrated stream files, the current client must <br/> be dedicated to the target stream. (See 'p4 help client'.) <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. Moved source files may <br/> cause target files to be scheduled for filename resolves. <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 -i flag enables merging between files that have no prior <br/> integration history. By default, 'p4 integrate' requires a prior <br/> integration in order to identify a base for merging. The -i flag <br/> allows the integration, and schedules the target file to be resolved <br/> using the first source revision as the merge base. <br/> <br/> The -o flag causes more merge information to be output. For each <br/> target file scheduled to be resolved, the base file revision and the <br/> source file revision are shown. (After running 'p4 integrate', the <br/> same information is available from 'p4 resolve -o'.) <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 -D flags modify the way deleted files are treated: <br/> <br/> -Dt If the target file has been deleted and the source <br/> file has changed, re-branch the source file on top <br/> of the target file instead of scheduling a resolve. <br/> <br/> -Ds If the source file has been deleted and the target <br/> file has changed, delete the target file instead of <br/> scheduling a resolve. <br/> <br/> -Di If the source file has been deleted and re-added, <br/> probe revisions that precede the deletion to find <br/> unintegrated revisions. By default, 'p4 integrate' <br/> starts probing at the last re-added revision. <br/> <br/> The -d flag is a shorthand for all -D flags used together. <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 -t flag propagates source filetypes instead of scheduling <br/> filetype conflicts to be resolved. <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/> 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/> </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# -d -f -h -i -o -n -m max -t -v <br/> -D<flags> -R<flags> <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 stream's branch view. (See <br/> 'p4 help stream'.) The source is the stream itself, and the target is <br/> the stream's parent. With -r, the direction is reversed. -P can be <br/> used to specify a parent stream other than the stream's actual parent. <br/> Note that to submit integrated stream files, the current client must <br/> be dedicated to the target stream. (See 'p4 help client'.) <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. Moved source files may <br/> cause target files to be scheduled for filename resolves. <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 -i flag enables merging between files that have no prior <br/> integration history. By default, 'p4 integrate' requires a prior <br/> integration in order to identify a base for merging. The -i flag <br/> allows the integration, and schedules the target file to be resolved <br/> using the first source revision as the merge base. <br/> <br/> The -o flag causes more merge information to be output. For each <br/> target file scheduled to be resolved, the base file revision and the <br/> source file revision are shown. (After running 'p4 integrate', the <br/> same information is available from 'p4 resolve -o'.) <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 -D flags modify the way deleted files are treated: <br/> <br/> -Dt If the target file has been deleted and the source <br/> file has changed, re-branch the source file on top <br/> of the target file instead of scheduling a resolve. <br/> <br/> -Ds If the source file has been deleted and the target <br/> file has changed, delete the target file instead of <br/> scheduling a resolve. <br/> <br/> -Di If the source file has been deleted and re-added, <br/> probe revisions that precede the deletion to find <br/> unintegrated revisions. By default, 'p4 integrate' <br/> starts probing at the last re-added revision. <br/> <br/> The -d flag is a shorthand for all -D flags used together. <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 -t flag propagates source filetypes instead of scheduling <br/> filetype conflicts to be resolved. <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/> 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/> </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 -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. <br/> <br/> The -q flag suppresses normal output messages. Messages regarding <br/> errors or exceptional conditions are displayed. <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 -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. <br/> <br/> The -q flag suppresses normal output messages. Messages regarding <br/> errors or exceptional conditions are displayed. <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/> 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/> -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/> <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 uresolved. <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 Ingore whitespace changes. <br/> -dw Ingore 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/> </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] <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] -c changelist# <br/> p4 submit -i [-r -s -f option] <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. 'p4 opened' shows <br/> unsubmitted files 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/> 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 -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/> </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 -c changelist#] 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 or integrate <br/> and are unchanged or missing. Files with pending integration records <br/> are left open. The file arguments are optional 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 -c flag reverts files that are open in the specified changelist. <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 [files] <br/> p4 shelve -i [-f | -r] <br/> p4 shelve -r -c changelist# <br/> p4 shelve -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. <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. Only the user and client workspace of the <br/> pending changelist can replace its shelved files. <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/> </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 -k -q] [-m max] [file[revRange] ...] <br/> p4 sync [-L -n -q -s] [-m max] [file[revRange] ...] <br/> p4 sync [-L -n -p -q] [-m max] [file[revRange] ...] <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 -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 -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/> <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/> </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 changelist#] [-f] [file ...] <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/> By default, files can be unlocked only by the changelist owner. The <br/> -f flag enables you to unlock files in changelists owned by other <br/> users. The -f flag requires 'admin' access, which is granted by 'p4 <br/> protect'. <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# [-f -n] [-c changelist#] [file ...] <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 only permitted <br/> if both shelved file and opened file are 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 workspace file. <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 -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/> </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# -n -v -m max <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' use a stream's branch view. (See 'p4 help <br/> stream'.) The source is the stream itself, and the target is the <br/> stream's parent. With -r, the direction is reversed. -P can be used <br/> to specify a parent stream other than the stream's actual parent. <br/> Note that to submit copied stream files, the current client must <br/> be dedicated to the target stream. (See 'p4 help client'.) <br/> <br/> The -F flag can be used with -S to force copying even though the <br/> stream does not expect a copy to occur in the direction indicated. <br/> Normally 'p4 copy' enforces the expected flow of change dictated <br/> by the stream's spec. The 'p4 istat' command summarizes a stream's <br/> expected flow of change. <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 -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 -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/> </remarks> </member> <member name="M:Perforce.P4.Client.MergeFiles(Perforce.P4.Options,Perforce.P4.FileSpec,Perforce.P4.FileSpec[])"> <br/><b>p4 help merge</b> <br/> <br/> merge -- Merge one set of files into another <br/> <br/> p4 merge [options] fromFile[revRange] toFile <br/> p4 merge [options] -b branch [-r] [toFile[revRange] ...] <br/> p4 merge [options] -b branch -s fromFile[revRange] [toFile ...] <br/> p4 merge [options] -S stream [-P parent] [-F] [-r] [toFile[revRange] ...] <br/> <br/> options: -c changelist# -n -m max <br/> <br/> 'p4 merge' merges changes from one set of files (the 'source') into <br/> another (the 'target'). It is a simplified form of the 'p4 integrate' <br/> command. <br/> <br/> Using the client workspace as a staging area, 'p4 merge' branches 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 merged files to <br/> the depot. Unresolved files may not be submitted. Merged files can <br/> be shelved with 'p4 shelve' and abandoned with 'p4 revert'. The <br/> commands 'p4 integrated' and 'p4 filelog' display merge history. <br/> <br/> When 'p4 merge' schedules a workspace file to be resolved, it leaves <br/> it read-only. 'p4 resolve' can operate on a read-only file; for <br/> other pre-submit changes, 'p4 edit' must be used to make the file <br/> writable. <br/> <br/> Source and target files can be specified either on the 'p4 merge' <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/> Each file in the target is mapped to a file in the source. Mapping <br/> adjusts automatically for files that have been moved or renamed, as <br/> long as 'p4 move' was used to move/rename files. The scope of source <br/> and target file sets must include both old-named and new-named files <br/> for mappings to be adjusted. Moved source files may schedule moves <br/> to be resolved in target files. <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 <br/> on toFile, it refers to source revisions, not to target revisions. <br/> For details about revision specifiers, see 'p4 help revisions'. <br/> <br/> The -S flag makes 'p4 merge' use a stream's branch view. (See 'p4 <br/> help stream'.) The source is the stream itself, and the target is <br/> the stream's parent. With -r, the direction is reversed. -P can be <br/> used to specify a parent stream other than the stream's actual parent. <br/> Note that to submit merged stream files, the current client must <br/> be dedicated to the target stream. (See 'p4 help client'.) <br/> <br/> The -F flag can be used with -S to force merging even though the <br/> stream does not expect a merge to occur in the direction indicated. <br/> Normally 'p4 merge' enforces the expected flow of change dictated <br/> by the stream's spec. The 'p4 istat' command summarizes a stream's <br/> expected flow of change. <br/> <br/> The -b flag makes 'p4 merge' 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 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/> </member> <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 can only be used when the <br/> login request is for another user. <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 can only be used when the <br/> login request is for another user. <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] <br/> <br/> The logout command removes the ticket on the client. To resume using <br/> Perforce, the user must log in again. <br/> <br/> The -a flag invalidates the ticket on the server, which will log out <br/> all users of the ticket. <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. <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. <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.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.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="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 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: 'local', 'stream', 'remote', 'spec', or 'archive'. <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/> 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/> (Example: depot/...). For remote depots, this path <br/> refers to the remote server's namespace <br/> (Example: //depot/...). <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. <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> -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 stream's branch view. (See 'p4 <br/> help stream'.) The stream is the source, and its parent is the <br/> target. -P can be used to specify a parent stream other than the <br/> 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 specifies number of context lines. <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/> but 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] name <br/> p4 group -d [-a] name <br/> p4 group -o name <br/> p4 group -i [-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/> 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/> 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' 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="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> Maximum time for a command to run before timing out; </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.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.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 the StrDictListIterator object 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.#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(Perforce.P4.P4Server,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 -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/> 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 -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 -v flag enables you to delete files that are not synced to the <br/> client workspace. <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/> </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 choosen <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/> </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# -d -f -h -i -o -n -m max -t -v <br/> -D<flags> -R<flags> <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 stream's branch view. (See <br/> 'p4 help stream'.) The source is the stream itself, and the target is <br/> the stream's parent. With -r, the direction is reversed. -P can be <br/> used to specify a parent stream other than the stream's actual parent. <br/> Note that to submit integrated stream files, the current client must <br/> be dedicated to the target stream. (See 'p4 help client'.) <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. Moved source files may <br/> cause target files to be scheduled for filename resolves. <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 -i flag enables merging between files that have no prior <br/> integration history. By default, 'p4 integrate' requires a prior <br/> integration in order to identify a base for merging. The -i flag <br/> allows the integration, and schedules the target file to be resolved <br/> using the first source revision as the merge base. <br/> <br/> The -o flag causes more merge information to be output. For each <br/> target file scheduled to be resolved, the base file revision and the <br/> source file revision are shown. (After running 'p4 integrate', the <br/> same information is available from 'p4 resolve -o'.) <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 -D flags modify the way deleted files are treated: <br/> <br/> -Dt If the target file has been deleted and the source <br/> file has changed, re-branch the source file on top <br/> of the target file instead of scheduling a resolve. <br/> <br/> -Ds If the source file has been deleted and the target <br/> file has changed, delete the target file instead of <br/> scheduling a resolve. <br/> <br/> -Di If the source file has been deleted and re-added, <br/> probe revisions that precede the deletion to find <br/> unintegrated revisions. By default, 'p4 integrate' <br/> starts probing at the last re-added revision. <br/> <br/> The -d flag is a shorthand for all -D flags used together. <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 -t flag propagates source filetypes instead of scheduling <br/> filetype conflicts to be resolved. <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/> 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/> </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 -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. <br/> <br/> The -q flag suppresses normal output messages. Messages regarding <br/> errors or exceptional conditions are displayed. <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/> 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/> -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/> <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 uresolved. <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 Ingore whitespace changes. <br/> -dw Ingore 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/> </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] <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] -c changelist# <br/> p4 submit -i [-r -s -f option] <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. 'p4 opened' shows <br/> unsubmitted files 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/> 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 -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/> </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 -c changelist#] 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 or integrate <br/> and are unchanged or missing. Files with pending integration records <br/> are left open. The file arguments are optional 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 -c flag reverts files that are open in the specified changelist. <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 [files] <br/> p4 shelve -i [-f | -r] <br/> p4 shelve -r -c changelist# <br/> p4 shelve -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. <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. Only the user and client workspace of the <br/> pending changelist can replace its shelved files. <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/> </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 -k -q] [-m max] [file[revRange] ...] <br/> p4 sync [-L -n -q -s] [-m max] [file[revRange] ...] <br/> p4 sync [-L -n -p -q] [-m max] [file[revRange] ...] <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 -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 -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/> <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/> </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 changelist#] [-f] [file ...] <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/> By default, files can be unlocked only by the changelist owner. The <br/> -f flag enables you to unlock files in changelists owned by other <br/> users. The -f flag requires 'admin' access, which is granted by 'p4 <br/> protect'. <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# [-f -n] [-c changelist#] [file ...] <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 only permitted <br/> if both shelved file and opened file are 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 workspace file. <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 -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/> </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# -n -v -m max <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' use a stream's branch view. (See 'p4 help <br/> stream'.) The source is the stream itself, and the target is the <br/> stream's parent. With -r, the direction is reversed. -P can be used <br/> to specify a parent stream other than the stream's actual parent. <br/> Note that to submit copied stream files, the current client must <br/> be dedicated to the target stream. (See 'p4 help client'.) <br/> <br/> The -F flag can be used with -S to force copying even though the <br/> stream does not expect a copy to occur in the direction indicated. <br/> Normally 'p4 copy' enforces the expected flow of change dictated <br/> by the stream's spec. The 'p4 istat' command summarizes a stream's <br/> expected flow of change. <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 -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 -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/> </remarks> </member> <member name="M:Perforce.P4.Options.#ctor(Perforce.P4.MergeFilesCmdFlags,System.String,System.String,System.String,System.Int32,System.Int32)"> <br/><b>p4 help merge</b> <br/> <br/> merge -- Merge one set of files into another <br/> <br/> p4 merge [options] fromFile[revRange] toFile <br/> p4 merge [options] -b branch [-r] [toFile[revRange] ...] <br/> p4 merge [options] -b branch -s fromFile[revRange] [toFile ...] <br/> p4 merge [options] -S stream [-P parent] [-F] [-r] [toFile[revRange] ...] <br/> <br/> options: -c changelist# -n -m max <br/> <br/> 'p4 merge' merges changes from one set of files (the 'source') into <br/> another (the 'target'). It is a simplified form of the 'p4 integrate' <br/> command. <br/> <br/> Using the client workspace as a staging area, 'p4 merge' branches 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 merged files to <br/> the depot. Unresolved files may not be submitted. Merged files can <br/> be shelved with 'p4 shelve' and abandoned with 'p4 revert'. The <br/> commands 'p4 integrated' and 'p4 filelog' display merge history. <br/> <br/> When 'p4 merge' schedules a workspace file to be resolved, it leaves <br/> it read-only. 'p4 resolve' can operate on a read-only file; for <br/> other pre-submit changes, 'p4 edit' must be used to make the file <br/> writable. <br/> <br/> Source and target files can be specified either on the 'p4 merge' <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/> Each file in the target is mapped to a file in the source. Mapping <br/> adjusts automatically for files that have been moved or renamed, as <br/> long as 'p4 move' was used to move/rename files. The scope of source <br/> and target file sets must include both old-named and new-named files <br/> for mappings to be adjusted. Moved source files may schedule moves <br/> to be resolved in target files. <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 <br/> on toFile, it refers to source revisions, not to target revisions. <br/> For details about revision specifiers, see 'p4 help revisions'. <br/> <br/> The -S flag makes 'p4 merge' use a stream's branch view. (See 'p4 <br/> help stream'.) The source is the stream itself, and the target is <br/> the stream's parent. With -r, the direction is reversed. -P can be <br/> used to specify a parent stream other than the stream's actual parent. <br/> Note that to submit merged stream files, the current client must <br/> be dedicated to the target stream. (See 'p4 help client'.) <br/> <br/> The -F flag can be used with -S to force merging even though the <br/> stream does not expect a merge to occur in the direction indicated. <br/> Normally 'p4 merge' enforces the expected flow of change dictated <br/> by the stream's spec. The 'p4 istat' command summarizes a stream's <br/> expected flow of change. <br/> <br/> The -b flag makes 'p4 merge' 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 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/> </member> <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 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. This status is reported by 'p4 fixes'. <br/> The 'p4 fix' and 'p4 change' (of a submitted changelist) and 'p4 submit' <br/> (of a pending changelist) commands set the job's status to the fix's <br/> status for each job associated with the change. If the fix's status <br/> 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/> 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] 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. <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 behaviour. <br/> <br/> submitunchanged All open files are submitted (default). <br/> <br/> revertunchanged Files that have content or type changes <br/> are submitted. Unchanged files are <br/> reverted. <br/> <br/> leaveunchanged Files that have content or type changes <br/> are submitted. Unchanged files are moved <br/> 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/> 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/> 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. <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, it is ignored. <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/> <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] 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. <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 behaviour. <br/> <br/> submitunchanged All open files are submitted (default). <br/> <br/> revertunchanged Files that have content or type changes <br/> are submitted. Unchanged files are <br/> reverted. <br/> <br/> leaveunchanged Files that have content or type changes <br/> are submitted. Unchanged files are moved <br/> 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/> 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/> 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. <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, it is ignored. <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/> <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/> <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*'. -E makes <br/> the matching case-insensitive. <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/> <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] [changelist#] <br/> p4 change -d [-f -s] changelist# <br/> p4 change -o [-s] [-f] [changelist#] <br/> p4 change -i [-s] [-f | -u] <br/> p4 change -t restricted | public [-f | -u] 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. The -f flag requires 'admin' access granted by 'p4 <br/> protect'. The -f and -u flags are mutually 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 -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) change <br/> is accessible to its owner. Public changes are accessible to all <br/> users. This setting affects the output of the 'p4 change', <br/> 'p4 changes', and 'p4 describe' commands. <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] [changelist#] <br/> p4 change -d [-f -s] changelist# <br/> p4 change -o [-s] [-f] [changelist#] <br/> p4 change -i [-s] [-f | -u] <br/> p4 change -t restricted | public [-f | -u] 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. The -f flag requires 'admin' access granted by 'p4 <br/> protect'. The -f and -u flags are mutually 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 -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) change <br/> is accessible to its owner. Public changes are accessible to all <br/> users. This setting affects the output of the 'p4 change', <br/> 'p4 changes', and 'p4 describe' commands. <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 pending, shelved or <br/> submitted changelists. <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] name <br/> p4 group -d [-a] name <br/> p4 group -o name <br/> p4 group -i [-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/> 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' 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] [[[-i] user | group] | [-v [group]]] <br/> <br/> List all user groups defined in the server. 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 -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 the specified group. <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 <br/> that the user be an operator or have 'super' access granted by <br/> '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/> </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 -o localFile -q] file[revRange] ... <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 -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/> </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> -s -S -f] 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 or shelved change is restricted, the description is hidden <br/> unless the user is the owner of the change or has list permission for <br/> at least one file in the change. To view restricted pending (not <br/> shelved) changes, the user must be the owner of the 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 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/> <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/> </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/>info -- Display client/server information <br/> <br/>p4 info [-s] <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). </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 -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/> 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 -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 -v flag enables you to delete files that are not synced to the <br/> client workspace. <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/> </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 choosen <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/> </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# -d -f -h -i -o -n -m max -t -v <br/> -D<flags> -R<flags> <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 stream's branch view. (See <br/> 'p4 help stream'.) The source is the stream itself, and the target is <br/> the stream's parent. With -r, the direction is reversed. -P can be <br/> used to specify a parent stream other than the stream's actual parent. <br/> Note that to submit integrated stream files, the current client must <br/> be dedicated to the target stream. (See 'p4 help client'.) <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. Moved source files may <br/> cause target files to be scheduled for filename resolves. <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 -i flag enables merging between files that have no prior <br/> integration history. By default, 'p4 integrate' requires a prior <br/> integration in order to identify a base for merging. The -i flag <br/> allows the integration, and schedules the target file to be resolved <br/> using the first source revision as the merge base. <br/> <br/> The -o flag causes more merge information to be output. For each <br/> target file scheduled to be resolved, the base file revision and the <br/> source file revision are shown. (After running 'p4 integrate', the <br/> same information is available from 'p4 resolve -o'.) <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 -D flags modify the way deleted files are treated: <br/> <br/> -Dt If the target file has been deleted and the source <br/> file has changed, re-branch the source file on top <br/> of the target file instead of scheduling a resolve. <br/> <br/> -Ds If the source file has been deleted and the target <br/> file has changed, delete the target file instead of <br/> scheduling a resolve. <br/> <br/> -Di If the source file has been deleted and re-added, <br/> probe revisions that precede the deletion to find <br/> unintegrated revisions. By default, 'p4 integrate' <br/> starts probing at the last re-added revision. <br/> <br/> The -d flag is a shorthand for all -D flags used together. <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 -t flag propagates source filetypes instead of scheduling <br/> filetype conflicts to be resolved. <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/> 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/> </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 -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. <br/> <br/> The -q flag suppresses normal output messages. Messages regarding <br/> errors or exceptional conditions are displayed. <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/> 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/> -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/> <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 uresolved. <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 Ingore whitespace changes. <br/> -dw Ingore 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/> </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] <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] -c changelist# <br/> p4 submit -i [-r -s -f option] <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. 'p4 opened' shows <br/> unsubmitted files 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/> 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 -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/> </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 -c changelist#] 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 or integrate <br/> and are unchanged or missing. Files with pending integration records <br/> are left open. The file arguments are optional 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 -c flag reverts files that are open in the specified changelist. <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 [files] <br/> p4 shelve -i [-f | -r] <br/> p4 shelve -r -c changelist# <br/> p4 shelve -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. <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. Only the user and client workspace of the <br/> pending changelist can replace its shelved files. <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/> </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 -k -q] [-m max] [file[revRange] ...] <br/> p4 sync [-L -n -q -s] [-m max] [file[revRange] ...] <br/> p4 sync [-L -n -p -q] [-m max] [file[revRange] ...] <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 -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 -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/> <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/> </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 changelist#] [-f] [file ...] <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/> By default, files can be unlocked only by the changelist owner. The <br/> -f flag enables you to unlock files in changelists owned by other <br/> users. The -f flag requires 'admin' access, which is granted by 'p4 <br/> protect'. <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# [-f -n] [-c changelist#] [file ...] <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 only permitted <br/> if both shelved file and opened file are 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 workspace file. <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 -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/> </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# -n -v -m max <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' use a stream's branch view. (See 'p4 help <br/> stream'.) The source is the stream itself, and the target is the <br/> stream's parent. With -r, the direction is reversed. -P can be used <br/> to specify a parent stream other than the stream's actual parent. <br/> Note that to submit copied stream files, the current client must <br/> be dedicated to the target stream. (See 'p4 help client'.) <br/> <br/> The -F flag can be used with -S to force copying even though the <br/> stream does not expect a copy to occur in the direction indicated. <br/> Normally 'p4 copy' enforces the expected flow of change dictated <br/> by the stream's spec. The 'p4 istat' command summarizes a stream's <br/> expected flow of change. <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 -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 -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/> </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> <member name="M:Perforce.P4.MergeFilesCmdOptions.#ctor(Perforce.P4.MergeFilesCmdFlags,System.String,System.String,System.String,System.Int32,System.Int32)"> <br/><b>p4 help merge</b> <br/> <br/> merge -- Merge one set of files into another <br/> <br/> p4 merge [options] fromFile[revRange] toFile <br/> p4 merge [options] -b branch [-r] [toFile[revRange] ...] <br/> p4 merge [options] -b branch -s fromFile[revRange] [toFile ...] <br/> p4 merge [options] -S stream [-P parent] [-F] [-r] [toFile[revRange] ...] <br/> <br/> options: -c changelist# -n -m max <br/> <br/> 'p4 merge' merges changes from one set of files (the 'source') into <br/> another (the 'target'). It is a simplified form of the 'p4 integrate' <br/> command. <br/> <br/> Using the client workspace as a staging area, 'p4 merge' branches 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 merged files to <br/> the depot. Unresolved files may not be submitted. Merged files can <br/> be shelved with 'p4 shelve' and abandoned with 'p4 revert'. The <br/> commands 'p4 integrated' and 'p4 filelog' display merge history. <br/> <br/> When 'p4 merge' schedules a workspace file to be resolved, it leaves <br/> it read-only. 'p4 resolve' can operate on a read-only file; for <br/> other pre-submit changes, 'p4 edit' must be used to make the file <br/> writable. <br/> <br/> Source and target files can be specified either on the 'p4 merge' <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/> Each file in the target is mapped to a file in the source. Mapping <br/> adjusts automatically for files that have been moved or renamed, as <br/> long as 'p4 move' was used to move/rename files. The scope of source <br/> and target file sets must include both old-named and new-named files <br/> for mappings to be adjusted. Moved source files may schedule moves <br/> to be resolved in target files. <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 <br/> on toFile, it refers to source revisions, not to target revisions. <br/> For details about revision specifiers, see 'p4 help revisions'. <br/> <br/> The -S flag makes 'p4 merge' use a stream's branch view. (See 'p4 <br/> help stream'.) The source is the stream itself, and the target is <br/> the stream's parent. With -r, the direction is reversed. -P can be <br/> used to specify a parent stream other than the stream's actual parent. <br/> Note that to submit merged stream files, the current client must <br/> be dedicated to the target stream. (See 'p4 help client'.) <br/> <br/> The -F flag can be used with -S to force merging even though the <br/> stream does not expect a merge to occur in the direction indicated. <br/> Normally 'p4 merge' enforces the expected flow of change dictated <br/> by the stream's spec. The 'p4 istat' command summarizes a stream's <br/> expected flow of change. <br/> <br/> The -b flag makes 'p4 merge' 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 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/> </member> <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 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. This status is reported by 'p4 fixes'. <br/> The 'p4 fix' and 'p4 change' (of a submitted changelist) and 'p4 submit' <br/> (of a pending changelist) commands set the job's status to the fix's <br/> status for each job associated with the change. If the fix's status <br/> 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/> 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] 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. <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 behaviour. <br/> <br/> submitunchanged All open files are submitted (default). <br/> <br/> revertunchanged Files that have content or type changes <br/> are submitted. Unchanged files are <br/> reverted. <br/> <br/> leaveunchanged Files that have content or type changes <br/> are submitted. Unchanged files are moved <br/> 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/> 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/> 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. <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, it is ignored. <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/> <br/> </remarks> </member> <member name="M:Perforce.P4.ClientCmdOptions.#ctor(Perforce.P4.ClientCmdFlags,System.String,System.String,System.Int32)"> <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] 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. <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 behaviour. <br/> <br/> submitunchanged All open files are submitted (default). <br/> <br/> revertunchanged Files that have content or type changes <br/> are submitted. Unchanged files are <br/> reverted. <br/> <br/> leaveunchanged Files that have content or type changes <br/> are submitted. Unchanged files are moved <br/> 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/> 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/> 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. <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, it is ignored. <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/> <br/> </remarks> </member> <member name="T:Perforce.P4.ClientsCmdFlags"> <summary> Flags for the clients command. </summary> </member> <member name="F:Perforce.P4.ClientsCmdFlags.None"> <summary> No flags. </summary> </member> <member name="F:Perforce.P4.ClientsCmdFlags.IncludeTime"> <summary> The -t flag displays the time as well as the date. </summary> </member> <member name="F:Perforce.P4.ClientsCmdFlags.IgnoreCase"> <summary> The -e nameFilter flag lists workspaces with a name that matches the nameFilter pattern, for example: -e 'svr-dev-rel*'. -E makes the matching case-insensitive. </summary> </member> <member name="T:Perforce.P4.ClientsCmdOptions"> <summary> Clients command options </summary> </member> <member name="M:Perforce.P4.ClientsCmdOptions.#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/> <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*'. -E makes <br/> the matching case-insensitive. <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/> <br/> </remarks> </member> <member name="T:Perforce.P4.ChangeCmdFlags"> <summary> Flags for the change command. </summary> </member> <member name="F:Perforce.P4.ChangeCmdFlags.None"> <summary> No flags. </summary> </member> <member name="F:Perforce.P4.ChangeCmdFlags.Delete"> <summary> The -d flag deletes a pending changelist, if it has no opened files and no pending fixes associated with it. Use 'p4 opened -a' to report on opened files and 'p4 reopen' to move them to another changelist. Use 'p4 fixes -c changelist#' to report on pending fixes and 'p4 fix -d -c changelist# jobs...' to delete pending fixes. The changelist can be deleted only by the user and client who created it, or by a user with 'admin' privilege using the -f flag. </summary> </member> <member name="F:Perforce.P4.ChangeCmdFlags.Output"> <summary> The -o flag writes the changelist specification to the standard output. The user's editor is not invoked. </summary> </member> <member name="F:Perforce.P4.ChangeCmdFlags.Input"> <summary> The -i flag reads a changelist specification from the standard input. The user's editor is not invoked. </summary> </member> <member name="F:Perforce.P4.ChangeCmdFlags.Force"> <summary> The -f flag forces the update or deletion of other users' pending changelists. -f can also force the deletion of submitted changelists after they have been emptied of files using 'p4 obliterate'. By default, submitted changelists cannot be changed. The -f flag can also force display of the 'Description' field in a restricted changelist. The -f flag requires 'admin' access granted by 'p4 protect'. The -f and -u flags are mutually exclusive. </summary> </member> <member name="F:Perforce.P4.ChangeCmdFlags.Update"> <summary> The -u flag can force the update of a submitted change by the owner of the change. Only the Jobs, Type, and Description fields can be changed using the -u flag. The -f and -u flags cannot be used in the same change command. </summary> </member> <member name="F:Perforce.P4.ChangeCmdFlags.IncludeJobs"> <summary> The -s flag extends the list of jobs to include the fix status for each job. On new changelists, the fix status begins as the special status 'ignore', which, if left unchanged simply excludes the job from those being fixed. Otherwise, the fix status, like that applied with 'p4 fix -s', becomes the job's status when the changelist is committed. Note that this option exists to support integration with external defect trackers. </summary> </member> <member name="T:Perforce.P4.ChangeCmdOptions"> <summary> Change command options. </summary> </member> <member name="M:Perforce.P4.ChangeCmdOptions.#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] [changelist#] <br/> p4 change -d [-f -s] changelist# <br/> p4 change -o [-s] [-f] [changelist#] <br/> p4 change -i [-s] [-f | -u] <br/> p4 change -t restricted | public [-f | -u] 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. The -f flag requires 'admin' access granted by 'p4 <br/> protect'. The -f and -u flags are mutually 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 -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) change <br/> is accessible to its owner. Public changes are accessible to all <br/> users. This setting affects the output of the 'p4 change', <br/> 'p4 changes', and 'p4 describe' commands. <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.ChangeCmdOptions.#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] [changelist#] <br/> p4 change -d [-f -s] changelist# <br/> p4 change -o [-s] [-f] [changelist#] <br/> p4 change -i [-s] [-f | -u] <br/> p4 change -t restricted | public [-f | -u] 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. The -f flag requires 'admin' access granted by 'p4 <br/> protect'. The -f and -u flags are mutually 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 -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) change <br/> is accessible to its owner. Public changes are accessible to all <br/> users. This setting affects the output of the 'p4 change', <br/> 'p4 changes', and 'p4 describe' commands. <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="T:Perforce.P4.ChangesCmdFlags"> <summary> Flags for the changes command. </summary> </member> <member name="F:Perforce.P4.ChangesCmdFlags.None"> <summary> No flags. </summary> </member> <member name="F:Perforce.P4.ChangesCmdFlags.IncludeIntegrated"> <summary> The -i flag also includes any changelists integrated into the specified files. </summary> </member> <member name="F:Perforce.P4.ChangesCmdFlags.IncludeTime"> <summary> The -t flag displays the time as well as the date. </summary> </member> <member name="F:Perforce.P4.ChangesCmdFlags.FullDescription"> <summary> The -l flag displays the full text of the changelist descriptions. </summary> </member> <member name="F:Perforce.P4.ChangesCmdFlags.LongDescription"> <summary> The -L flag displays the changelist descriptions, truncated to 250 characters if longer. </summary> </member> <member name="F:Perforce.P4.ChangesCmdFlags.ViewRestricted"> <summary> The -f flag enables admin users to view restricted changes. </summary> </member> <member name="T:Perforce.P4.ChangeListStatus"> <summary> Flags for the status of a changelist. </summary> </member> <member name="F:Perforce.P4.ChangeListStatus.None"> <summary> No status specified. </summary> </member> <member name="F:Perforce.P4.ChangeListStatus.Pending"> <summary> Pending changelist. </summary> </member> <member name="F:Perforce.P4.ChangeListStatus.Shelved"> <summary> Shelved changelist. </summary> </member> <member name="F:Perforce.P4.ChangeListStatus.Submitted"> <summary> Submitted changelist. </summary> </member> <member name="T:Perforce.P4.ChangesCmdOptions"> <summary> Changes command options. </summary> </member> <member name="M:Perforce.P4.ChangesCmdOptions.#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 pending, shelved or <br/> submitted changelists. <br/> <br/> The -u user flag displays only changes owned by the specified user. <br/> <br/> </remarks> </member> <member name="T:Perforce.P4.GroupCmdFlags"> <summary> Flags for the group command. </summary> </member> <member name="F:Perforce.P4.GroupCmdFlags.None"> <summary> No flags. </summary> </member> <member name="F:Perforce.P4.GroupCmdFlags.Delete"> <summary> The -d flag deletes a pending changelist, if it has no opened files and no pending fixes associated with it. Use 'p4 opened -a' to report on opened files and 'p4 reopen' to move them to another changelist. Use 'p4 fixes -c changelist#' to report on pending fixes and 'p4 fix -d -c changelist# jobs...' to delete pending fixes. The changelist can be deleted only by the user and client who created it, or by a user with 'admin' privilege using the -f flag. </summary> </member> <member name="F:Perforce.P4.GroupCmdFlags.Output"> <summary> The -o flag writes the changelist specification to the standard output. The user's editor is not invoked. </summary> </member> <member name="F:Perforce.P4.GroupCmdFlags.Input"> <summary> The -i flag reads a changelist specification from the standard input. The user's editor is not invoked. </summary> </member> <member name="F:Perforce.P4.GroupCmdFlags.OwnerAccess"> <summary> The -a flag enables a user without 'super' access to modify the group if that user is an 'owner' of that group. Group owners are specified in the 'Owners' field of the group spec. </summary> </member> <member name="F:Perforce.P4.GroupCmdFlags.AdminAdd"> <summary> The -A flag enables a user with 'admin' access to add a new group. Existing groups may not be modified when this flag is used. </summary> </member> <member name="T:Perforce.P4.GroupCmdOptions"> <summary> Group command options. </summary> </member> <member name="M:Perforce.P4.GroupCmdOptions.#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] name <br/> p4 group -d [-a] name <br/> p4 group -o name <br/> p4 group -i [-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/> 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/> 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' flag by a qualified user. <br/> <br/> </remarks> </member> <member name="T:Perforce.P4.GroupsCmdFlags"> <summary> Flags for the groups command. </summary> </member> <member name="F:Perforce.P4.GroupsCmdFlags.None"> <summary> No flags. </summary> </member> <member name="F:Perforce.P4.GroupsCmdFlags.IncludeIndirect"> <summary> The -i flag also displays groups that the user or group belongs to indirectly by means of membership in subgroups. (The group parameter for the command can be a user or group name) </summary> </member> <member name="F:Perforce.P4.GroupsCmdFlags.IncludeAllValues"> <summary> The -v flag displays the MaxResults, MaxScanRows, MaxLockTime, and Timeout values for the specified group. </summary> </member> <member name="T:Perforce.P4.GroupsCmdOptions"> <summary> Groups command options. </summary> </member> <member name="T:Perforce.P4.JobCmdFlags"> <summary> Flags for the job command. </summary> </member> <member name="F:Perforce.P4.JobCmdFlags.None"> <summary> No flags. </summary> </member> <member name="F:Perforce.P4.JobCmdFlags.Delete"> <summary> The -d flag deletes the specified job. You cannot delete a job if it has pending or submitted fixes associated with it. </summary> </member> <member name="F:Perforce.P4.JobCmdFlags.Output"> <summary> The -o flag writes the job specification to the standard output. The user's editor is not invoked. </summary> </member> <member name="F:Perforce.P4.JobCmdFlags.Input"> <summary> The -i flag reads a job specification from the standard input. The user's editor is not invoked. </summary> </member> <member name="F:Perforce.P4.JobCmdFlags.Force"> <summary> The -f flag enables you set fields that are read-only by default. The -f flag requires 'admin' access, which is granted using the 'p4 protect' command. </summary> </member> <member name="T:Perforce.P4.JobCmdOptions"> <summary> Job command options </summary> </member> <member name="M:Perforce.P4.JobCmdOptions.#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="T:Perforce.P4.JobsCmdFlags"> <summary> Flags for the jobs command. </summary> </member> <member name="F:Perforce.P4.JobsCmdFlags.None"> <summary> No flags. </summary> </member> <member name="F:Perforce.P4.JobsCmdFlags.IncludeIntegratedFixes"> <summary> The -i flag includes any fixes made by changelists integrated into the specified files. </summary> </member> <member name="F:Perforce.P4.JobsCmdFlags.LongDescriptions"> <summary> The -l flag produces long output with the full text of the job descriptions. </summary> </member> <member name="F:Perforce.P4.JobsCmdFlags.ReverseSort"> <summary> The -r flag sorts the jobs in reverse order (by job name). </summary> </member> <member name="F:Perforce.P4.JobsCmdFlags.RebuildJobsTable"> <summary> The -R flag rebuilds the jobs table and reindexes each job, which is necessary after upgrading to 98.2. 'p4 jobs -R' requires that that the user be an operator or have 'super' access granted by 'p4 protect'. </summary> </member> <member name="T:Perforce.P4.JobsCmdOptions"> <summary> Jobs command options </summary> </member> <member name="M:Perforce.P4.JobsCmdOptions.#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 <br/> that the user be an operator or have 'super' access granted by <br/> 'p4 protect'. <br/> <br/> </remarks> </member> <member name="T:Perforce.P4.FilesCmdFlags"> <summary> Flags for the files command. </summary> </member> <member name="F:Perforce.P4.FilesCmdFlags.None"> <summary> No flags. </summary> </member> <member name="F:Perforce.P4.FilesCmdFlags.AllRevisions"> <summary> The -a flag displays all revisions within the specific range, rather than just the highest revision in the range. </summary> </member> <member name="F:Perforce.P4.FilesCmdFlags.IncludeArchives"> <summary> The -A flag displays files in archive depots. </summary> </member> <member name="T:Perforce.P4.FilesCmdOptions"> <summary> Files command options </summary> </member> <member name="M:Perforce.P4.FilesCmdOptions.#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="T:Perforce.P4.FileLogCmdFlags"> <summary> Flags for the filelog command. </summary> </member> <member name="F:Perforce.P4.FileLogCmdFlags.None"> <summary> No flags. </summary> </member> <member name="F:Perforce.P4.FileLogCmdFlags.IncludeInherited"> <summary> The -i flag, includes inherited file history. If a file was created by branching (using 'p4 integrate'), filelog lists the revisions of the file's ancestors up to the branch points that led to the specified revision. File history inherited by renaming (using 'p4 move') is always displayed regardless of whether -i is specified. </summary> </member> <member name="F:Perforce.P4.FileLogCmdFlags.DisplayContentHistory"> <summary> The -h flag,
# | Change | User | Description | Committed | |
---|---|---|---|---|---|
#1 | 15071 | alan_petersen |
Populate -o //guest/perforce_software/piper/... //guest/alan_petersen/piper/.... |
||
//guest/perforce_software/piper/windows/main/lib/p4api.net.XML | |||||
#3 | 13571 | alan_petersen | Lots 'o bug fixes | ||
#2 | 12025 | alan_petersen |
**** MEGA UPDATE **** UPDATE - reworked initial calls to GetPerforceHelper to avoid the 'alive' check - fixed error in the connection failed logic to launch the dialog using a dispatcher (without this, a threading error occurs if this code was called from a background thread) UPDATE - reworked initial calls to GetPerforceHelper to avoid the 'alive' check - fixed error in the connection failed logic to launch the dialog using a dispatcher (without this, a threading error occurs if this code was called from a background thread) reg script to add URL handler UPDATE: - updated P4.NET api to latest release ### Bug fixes: ### #84: DEFECT: submit single item should just have item checked in the current changelist - reworked the submit logic to take selected item(s) and move them to a new changelist. - failed submission restores files to original changelist and the new changelist is deleted #110: DEFECT: submit fails if changelist has shelved items - now that items are moved to a new changelist and then that is submitted, shelved items do not cause an issue. - shelved items are not automatically deleted -- they will need to be removed from the shelf manually #111: DEFECT: submit changelist should sort with checked items on top - added CompareTo to the ChangelistFile class to allow comparison for sorting #112: DEFECT: application will not open login dialog if server check fails - reworked helper creation logic to create most helpers when the application first starts - fixed bug in which cached Repository object was retrieved (rather than the new Repo) ### Bug fixes: ### #85: DEFECT: submit error not useful - submit errors now list files that could not be submitted (and caused submit failure) #113: DEFECT: watcher does not restart if submit cancelled - cancel button was not associated with any operations (it just made the dialog go away). Now cancel calls Utility.StartBackgroundProcesses(). UPDATE: - combined syncworker and refreshworker into 1 background thread, rather than 2 separate threads - UI refresh now occurs immediately after sync - removed refreshworker class, settings, etc. ### Bug fixes: ### #114: Defect: Deleted items are not unsynced from workspace - fixed two issues: - sync worker was not starting correctly - sync / refresh being on different schedules was causing some strange behavior UPDATE: - modified CheckInButtonEnabled logic in ToolBarViewModel to enable the button if a valid client is configured. - previous version had more complex logic and cached data, but refresh was slow and this is now simpler. ### Bug fixes: ### #25: Defect: Ability to check in part of the move operation - modified checkbox click logic to see if file action is move/add or move/delete and if it is, an fstat is executed to get the source (MovedFile) and then the associated line in the table is checked/unchecked. This will prevent a user from deselecting part of a move operation #107: Defect: Unsync from computer not working - modified 'unsync from workspace' logic to use exclude mapping if directory has a parent directory that is mapped - modified code that gets client mappings for depot paths to use the raw 'p4 where' command rather than the API -- the API results don't let you distinguish between directories that are mapped and those that are excluded. The p4 where command tagged output includes an extra field 'unmap' for paths that are excluded. this is probably a bug in the API #116: DEFECT: submit reports changelist -1 if no files submitted - modified logic in command helper to only display the changelist ID if it is greater than 0 (i.e. files were submitted) #117: Defect: Desi application crashes on delete folder - modified logic in the CommandHelper delete method to check to see if any files are openeed in the directory path, and if so the delete is prevented and a message dialog is displayed indicating that the folder could not be deleted. #49: Defect: Desi throws exception when internet connection is lost - modified the unhandled exception method in App.xaml.cs to give the user the option to quit or reopen the application - modified the GetRepository logic in PerforceHelper to avoid the try/catch and keep the cached repo (for performance) UPDATE: - modified CommandHelper.RevertFiles to stop / start the background processes (sync, watchdog) to hopefully prevent watchdog from seeing files appear in the workspace - modified watchdog with slight delay and then check to see if file exists when issuing a create (p4 add) ### Bug fixes: ### #82: DEFECT: strange add/remove behavior with Microsoft Excel - was able to replicate, added delay to logic in watchdog and a check to see if the created file actually exists -- these temporary excel files appear and disappear quickly -- the delay can be increased if files still appear in DESI #85: DEFECT: submit error not useful - modified submit logic in CommandHelper to display the error message if the details are empty (this happens sometimes, apparently) #115: Defect: File watchdog does not register deletes and moves from the explorer - modified watchdog code a little to try to catch deletes and moves better - files with .tmp extension were completely ignored, which could cause issues if there are actual files with .tmp extensions #118: Defect: search does not return result if keywords are from two different source (filename + content) - modified search query building logic to match that used by mac DESI #119: Defect : Checkout folders should be deleted - modified logic used when sending a folder to the trash to ignore files marked for add when running 'p4 opened' #83: DEFECT: folder history should have button to show files in changelist - added new window to display changelist information, specifically the description, modification date, and files (with actions) in the changelist. - currently, this opens up as a modal window (dialog) that can be resized, etc. I thought that it was better than a fixed window attached to the main DESI window. #60: Defect: Search should be restricted to current folder - added new toggle to the 'more options' section that gets populated if the user has a folder selected in the Workspace or Server tabs when s/he performs a search. #49: Defect: Desi throws exception when internet connection is lost - Modified logic in App.xaml.cs to do the following when an unhandled exception is caught: - stops background processes (to prevent double dialog seen in latest reported error) - uses the DialogManager to display dialog aligned at the top of the window, giving the user the option of restarting or quitting the application #118: Defect: search does not return result if keywords are from two different source (filename + content) - Modified logic in SearchHelper.cs to format the search terms with wildcards (*) before and after each term #60: Defect: Search should be restricted to current folder - modified logic to keep selected folder if the current view is on the search screen #120: Defect : Adding Same File with add button - Changed add logic in ToolBar.xaml.cs to use the Utility.CopyFileToDirectory method to copy files to the destination directory, adding "(Copy n)" to the filenames if a file with that name already exists in the destination #83: DEFECT: folder history should have button to show files in changelist - Modified logic executed when clicking the rollback button in the FolderHistory.xaml.cs file to display a wait dialog when rolling back, which will help prevent the perception of the application "locking up" #101: DEFECT: Add button not working for favorite - modified AddFile and AddFolder toolbar button logic to enable the buttons if the favorite points to a workspace folder (as opposed to a server folder) #102: DEFECT: Favorite pointing to folder on server tab should have server background - modified FavoritesView.xaml to display background contingent on favorite item's source (workspace or server) - re-worked FavoritesViewModel as datacontext for FavoritesView - added server check logic to FavoritesViewModel #95: DEFECT: Positioning of add tag popup - Due to differences in popup positioning between Win7 and Win8, the only positioning that seemed to be consistent was "center" on the parent position. I modified the Sidebar.xaml to position the Add Tag popup relative to the + button. #86: DEFECT: workspace thumbnails - updated ListingItemInfoViewModel.cs to try to generate png thumbnail of file if the file's action is Edit, Add or MoveAdd, which might indicate that the file has changed. #93: Defect: Bread crumbs cuts off if the path is too long - modified ControlTemplate in BreadcrumbBar.xaml to include a thin (5px) horizontal scrollbar on the bottom UPDATE: Added new logging facility (available via the View menu). Currently, logging is set to "ALL" (which means "everything") but for release this will be set to INFO or WARN. The user can change the log level by opening the log window and selecting the log level from the combo box at the top. The Clear button clears the log, and the Save button allows the user to save the log to a file ### Bug fixes: ### #100: DEFECT: Copy/paste results in Windows "Cannot create directory" error - unable to replicate, added a new logging facility (Log window under the View menu) to provide more information #105: Defect: Object reference error pops up intermittently - unclear when this is happening... cleaned up the one place #49: Defect: Desi throws exception when internet connection is lost - Updated exception handler in App.xaml.cs to stop background processes and display integrated dialog (rather than standalone dialog) UPDATE: - update to logic regarding switching workspaces - update to breadcrumb logic to display breadcrumbs more accurately when the selection is changed ### Bug fixes: ### #121: DESI Screen not get updated - changing the workspace now clears the workspace grid and deselects the workspace selector, if it is already selected #121: DESI Screen not get updated - two null references were not being caught, resulting in application crashes under specific circumstances. these have now been fixed! - updated workspace selection logic to clear out old values (that was resulting in old data still present when the workspace is switched) #122: Drag/Drop Folder not working - modified logic for drag&drop to more intelligently handle a dropped item UPDATE: - modified sync button functionality - reports number of changes synchronized from server - waits for 20 seconds (or until the user clicks the OK button) ### Bug fixes: ### #123: Defect :Files Deleted is also displaying in Recently added - modified count of files during sync so this should be fine now #124: DEFECT: add button does not work when creating favorite tag - removed the add button (since it is superfluous anyway) and so users can just hit enter after typing in the tag name UPDATE: - modified "LOCKED BY" text in button to be left aligned ### Bug fixes: ### #125 DEFECT: submitting single moved item should also select corresponding deleted item - modified the SubmitFile method in CommandHelper to check to see if the file's action is MoveAdd, and if so, then to get the MovedFile attribute from the metadata (the corresponding delete) and select that too, so the submit dialog will have both items selected. #126 DEFECT: Licensing/version info - created 'About' menu under the 'Help' menu - added licenses to Resources/Licenses - added version information (derived from the project version data) #127 DEFECT: Toolbar items need tooltips - tooltips now available on buttons. note that tooltips are only visible for enabled buttons #128 DEFECT: Unversioned files show strange & useless modification timestamp + version number - modified ListingItemInfoViewModel.cs ModifiedDate method to return the string ---- if the timestamp is zero - modified ListingItemInfoViewModel.cs, adding a Revision property and having the method return {none} if the revision is not greater than zero. #129 DEFECT: Application window should have minimum size - MainWindow now has attributes MinHeight="400" MinWidth="550" which restrict how small the window can be made #130 DEFECT: Date format should be DD.MM.YYYY or YYYY-MM-DD, but not MM.DD.YYYY - modified ListingItemInfoViewModel.cs ModifiedDate method to return a formatted string, rather than having WPF format the date - modified VersionInfo.xaml to format the "CHECKED IN" field using the string formatter "yyyy/MM/dd HH:mm:ss" - modified VersionItem.cs to ensure that the date returned is expressed as local time (time is now retrieved from the metadata instead of the file history to ensure that it matches TZ-wise) #131 DEFECT: When entering Submit message, pressing <ENTER> starts submission instead of creating a new line - added AcceptsReturn="True" AcceptsTab="True" to the Changelist description field in the SubmitForm.xaml dialog #132 DEFECT: In menu bar there is no "Help" item to link to any help page or show support contact information - added help menu - TODO: need URL for help system #133 DEFECT: Tags names do not display underscore - modified tag display in ListingItemInfo.xaml to use TextBlock instead of Label UPDATE: added copyright and cleaned up usings removed unused method UPDATE: - modified favorites, tags, and breadcrumbs to use TextBox instead of Label (dealing with the deleted underscore issue) - removed unused BreadcrumbLabel user control ### Bug fixes: ### #124 DEFECT: add button does not work when creating favorite tag - modified tag display to be TextBox instead of label - modified positioning of add popup (again!) #127 DEFECT: Toolbar items need tooltips - added ToolTipService.ShowOnDisabled="true" to each toolbar button to get around strange issue where enabling/disabling button resulted in blank tooltips. Probably a good idea to have the tooltips always visible anyway (rather than only when buttons are enabled) #134 Defect : Breadcrumbs should also show the underscore sign. - updated to use TextBox instead of Label #130 DEFECT: Date format should be DD.MM.YYYY or YYYY-MM-DD, but not MM.DD.YYYY - modified FolderHistory.xaml to use ContentStringFormat="yyyy/MM/dd HH:mm:ss" for the "CHECKED IN" date format, which should provide consistency across the application now. UPDATE: - fixed error in which changelist could get orphaned if all files submitted were reverted ### Bug fixes: ### #136 Defect: Submit all folder option missing - added menu item "Submit all files" for mapped folders - added handler code for menu item - added CommandHelper SubmitFolder method to submit all files contained in a folder. ** NOTE: this needs to iterate over all files in the changelist, so for a changelist with many files, there could be a delay. #135 Defect: Keyboard navigation refinement - updated keyboard navigation code to provide more "smooth" navigation through the application #135 Defect: File watchdog does not monitor folder deletions - fixed copy/paste typo that existed in the folder deletion code that would cause the system to miss folders that are deleted. UPDATE: Adding code for msi installer generation Fixing dist script to deal with Debug or Release distros Changes to installer definition to create Desktop shortcut - fixes log window reopening that caused an error ### Bug fixes: ### #141 DEFECT: Adding files with strange characters causes crash - modified Add command in PerforceHelper to include the AddFilesCmdFlags.KeepWildcards option UPDATE: - fixed issue in which application would crash if URL supplied and the user was not logged in - added CleanChangelist method to PerforceHelper to cycle through list of changelist files to ensure that all files marked for add still exist on the local filesystem (they may have been deleted since they were added) - workspace watcher logic revamped to remove delays - removed shutdown of watchdog to prevent situations in which file modifications were missed - context menu text updated to "selected files" instead of "all files" ### Bug fixes: ### #151 Defect: On Submission fail, Files are becoming read only - logic now calls the CleanChangelist method before bringing up the submit dialog #145 Defect: Refresh on long folder paths leads to auto selection of random folders - refresh logic revisited -- refresh of a panel has been reworked to proceed one column at a time, synchronously. #149 Defect: Option to submit selected items from pending list and trash list is not available - context menu added for submission of files from Pending and Trash UPDATE: - modified MainWindow.cs and Utility.cs to call CleanChangelist when workspace is first selected - modified CleanChangelist in PerforceHelper.cs to do the following: - for each file in the changelist: - if action is Add, revert if local file no longer exists - if action is Move/Add, revert file and delete original file - if action is Edit, revert the edit and delete ### Bug fixes: ### #149 Defect: Option to submit selected items from pending list and trash list is not available - fixed typo (the font was really small!!) - fixed casting bug that caused Null exception #108 DEFECT? - reconcile on submit - added CleanChangelist method to perform "reconcile" options -- reconcile itself cannot detect when files are added or edited and then deleted locally #139 Defect: Rollback on folder does not delete files - updated PerforceHelper.cs to delete files correctly when a folder is rolled back #153: Defect : Move Action should get default selected if one get selected - fixed typo in context menu - updated SubmitFiles method in ContextMenuHelper.cs to do an fstat on files being submitted and select associated files if the action is MoveAdd or MoveDelete #49 Defect: Desi throws exception when internet connection is lost - updated PerforceHelper to test connection (with 5 second timeout) every time it is requested. #154 Defect: Weird behavior with folders with different upper case are mapped - updated various aspects of the code to make string comparisons case insensitive. #155 Defect : Cannot rename the Favorite Folder name - updated xaml to rearrange elements to make edit box visible again. UPDATE: - added Shanghai and Tokyo to drop down list - replaced IP addresses with hostnames - modified dist.cmd to create installer and copy to dist\Release directory if Release is the specified distribution ### Bug fixes: ### #147 Defect: Installer should add shortcut to start menu - updated Wix configuration to include start menu shortcut #129 DEFECT: Application window should have minimum size - sidebar now has auto-appearing 5-pixel wide scrollbar if the window height is not enough to accommodate the number of things in the sidebar UPDATE: - enlarged submit dialog (cannot make it resizable) - made submit datagrid columns resizable and sortable - added help URL to help menu (opens in default web browser) ### Bug fixes: ### #157 DEFECT: orphaned changelists - application now gathers changelist files when it starts - menu item in File menu to gather changelist files on demand UPDATE: - removed automatic "Gathering changes" functionality ### Bug fixes: ### #158 DEFECT: p4 urls open up new DESI instances - modified App.xml.cs to look for existing DESI processes and to set focus to the existing process and exit if there is already one running - added the P4Listener.cs helper class to create a named pipe to listen for p4:// URLs - modified App.xml.cs to send the URL to the named pipe if it is passed on the command line |
||
#1 | 11255 | alan_petersen | Rename/move file(s) | ||
//guest/perforce_software/piper/windows/lib/p4api.net.XML | |||||
#1 | 10761 | alan_petersen |
initial drop of Piper for Windows.... this version still has _many_ bugs (er... i mean "unintended features") but I will be updating it over the next week as more stability is added. |