From owner-svn-doc-all@FreeBSD.ORG Sun May 25 14:40:42 2014 Return-Path: Delivered-To: svn-doc-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0E89C5F9; Sun, 25 May 2014 14:40:42 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EDD9C2582; Sun, 25 May 2014 14:40:41 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s4PEefsh091336; Sun, 25 May 2014 14:40:41 GMT (envelope-from bcr@svn.freebsd.org) Received: (from bcr@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s4PEefUE091335; Sun, 25 May 2014 14:40:41 GMT (envelope-from bcr@svn.freebsd.org) Message-Id: <201405251440.s4PEefUE091335@svn.freebsd.org> From: Benedict Reuschling Date: Sun, 25 May 2014 14:40:41 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44950 - head/en_US.ISO8859-1/articles/p4-primer X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 May 2014 14:40:42 -0000 Author: bcr Date: Sun May 25 14:40:41 2014 New Revision: 44950 URL: http://svnweb.freebsd.org/changeset/doc/44950 Log: Huge whitespace change to make igor happy. Translators can ignore it. Modified: head/en_US.ISO8859-1/articles/p4-primer/article.xml Modified: head/en_US.ISO8859-1/articles/p4-primer/article.xml ============================================================================== --- head/en_US.ISO8859-1/articles/p4-primer/article.xml Sun May 25 13:39:55 2014 (r44949) +++ head/en_US.ISO8859-1/articles/p4-primer/article.xml Sun May 25 14:40:41 2014 (r44950) @@ -1,16 +1,25 @@ -
- +
- Perforce in &os; Development + + Perforce in &os; Development - ScottLong -
scottl@FreeBSD.org -
- + + + Scott + Long + + +
+ scottl@FreeBSD.org +
+ + @@ -23,446 +32,463 @@ $FreeBSD$ - - Introduction + + Introduction - The &os; project uses the Perforce - version control system to manage experimental projects that are - not ready for the main Subversion repository. - - - Availability, Documentation, and Resources - - While Perforce is a commercial - product, the client software for interacting with the server is - freely available from Perforce. It can be easily installed on - &os; via the devel/p4 - port or can be downloaded from the Perforce - web site at http://www.perforce.com/perforce/loadprog.html, - which also offers client applications for other OS's. - - While there is a GUI client available, most people use the - command line application called p4. This - document is written from the point of view of using this - command. - - Detailed documentation is available online at http://www.perforce.com/perforce/technical.html. - - Reading the Perforce User's Guide and - Perforce Command Reference is highly recommended. - The p4 application also contains an - extensive amount of online help accessible via p4 - help. - - The &os; Perforce server is - hosted on perforce.freebsd.org, - port 1666. The repository is browsable - online at http://p4web.freebsd.org. - - - - - Getting Started - - The first step to using Perforce is - to obtain an account on the server. If you already have a FreeBSD.org account, log into freefall, run the following command, and - enter a password that is not the same as your &os; login or any - other SSH passphrase: - - &prompt.user; /usr/local/bin/p4newuser - - Of course if you do not have a FreeBSD.org account, you will need to - coordinate with your sponsor. - - - An email will be sent to your &os; address that contains - the password you specified above in cleartext. Be sure to change - the password once your Perforce account - has been created! - - - The next step is to set the environment variables that - p4 needs, and verify that it can connect to the - server. The P4PORT variable is required to be set - for all operations, and specifies the appropriate - Perforce server to talk to. For the - &os; project, set it like so: - - &prompt.user; export P4PORT=perforce.freebsd.org:1666 - - - Users with shell access on the FreeBSD.org cluster may wish to tunnel - the Perforce client-server protocol via - an SSH tunnel, in which case the above string should be set to - localhost. - - - The &os; server also requires that the P4USER - and P4PASSWD variables be set. Use the username - and password from above, like so: + The &os; project uses the + Perforce version control system to + manage experimental projects that are not ready for the main + Subversion repository. + + + Availability, Documentation, and Resources + + While Perforce is a commercial + product, the client software for interacting with the server + is freely available from Perforce. It can be easily installed + on &os; via the devel/p4 port or can be + downloaded from the Perforce web + site at http://www.perforce.com/perforce/loadprog.html, + which also offers client applications for other OS's. + + While there is a GUI client available, most people use the + command line application called p4. This + document is written from the point of view of using this + command. + + Detailed documentation is available online at http://www.perforce.com/perforce/technical.html. + + Reading the Perforce User's Guide and + Perforce Command Reference is highly + recommended. The p4 application + also contains an extensive amount of online help accessible + via p4 help. + + The &os; Perforce server is + hosted on perforce.freebsd.org, port + 1666. The repository is browsable online + at http://p4web.freebsd.org. + + + + + Getting Started + + The first step to using Perforce + is to obtain an account on the server. If you already have a + FreeBSD.org + account, log into freefall, run the following + command, and enter a password that is not the same as your &os; + login or any other SSH passphrase: + + &prompt.user; /usr/local/bin/p4newuser + + Of course if you do not have a FreeBSD.org account, you + will need to coordinate with your sponsor. + + + An email will be sent to your &os; address that contains + the password you specified above in cleartext. Be sure to + change the password once your + Perforce account has been + created! + + + The next step is to set the environment variables that + p4 needs, and verify that it can connect to + the server. The P4PORT variable is required to + be set for all operations, and specifies the appropriate + Perforce server to talk to. For the + &os; project, set it like so: + + &prompt.user; export P4PORT=perforce.freebsd.org:1666 + + + Users with shell access on the FreeBSD.org cluster may + wish to tunnel the Perforce + client-server protocol via an SSH tunnel, in which case the + above string should be set to + localhost. + + + The &os; server also requires that the P4USER + and P4PASSWD variables be set. Use the username + and password from above, like so: - &prompt.user; export P4USER=username + &prompt.user; export P4USER=username &prompt.user; export P4PASSWD=password - Test that this works by running the following command: + Test that this works by running the following + command: - &prompt.user; p4 info + &prompt.user; p4 info - This should return a list of information about the server. If - it does not, check that you have the P4PORT - variable set correctly. - - - - Clients - - Perforce provides access to the - repository and tracks state on a per-client basis. In - Perforce terms, a client is a - specification that maps files and directories from the repository - to the local machine. Each user can have multiple clients, and - each client can access different or overlapping parts of the - repository. The client also specifies the root directory of the - file tree that it maps, and it specifies the machine that the tree - lives on. Thus, working on multiple machines requires that - multiple clients be used. - - Clients may be accessed via p4 client. - Running this command with no arguments will bring up a client - template in an editor, allowing you to create a new client - for your work. The important fields in this template are - explained below: - - - - Client: + This should return a list of information about the server. + If it does not, check that you have the P4PORT + variable set correctly. + + + + Clients + + Perforce provides access to the + repository and tracks state on a per-client basis. In + Perforce terms, a client is a + specification that maps files and directories from the + repository to the local machine. Each user can have multiple + clients, and each client can access different or overlapping + parts of the repository. The client also specifies the root + directory of the file tree that it maps, and it specifies the + machine that the tree lives on. Thus, working on multiple + machines requires that multiple clients be used. + + Clients may be accessed via p4 client. + Running this command with no arguments will bring up a client + template in an editor, allowing you to create a new client for + your work. The important fields in this template are explained + below: + + + + Client: + + + This is the name of the client spec. It can be + anything you want, but it must be unique within the + Perforce server. A naming + convention that is commonly used is + username_machinename, + which makes it easy to identify clients when browsing + them. A default name will be filled in that is just the + machine name. + + + + + Description: + + + This can contain a simple text description to help + identify the client. + + + + + Root: + + + This is the local directory that will serve as the + root directory of all the files in the client mapping. + This should be a unique location in your filesystem that + does not overlap with other files or + Perforce clients. + + + + + Options: + + + Most of the default options are fine, though it is + usually a good idea to make sure that the + and + options are present and do not have a + no prefix on them. Details about each + option are in the Perforce + docs. + + + + + LineEnd: + + + This handles CR-LF conversions and should be left to + the default unless you have special needs for it. + + + + + View: + + + This is where the server-to-local file mappings go. + The default is + + //depot/... //client/... + + This will map the entire + Perforce repository to the + Root directory of your client. + DO NOT USE THIS DEFAULT! The &os; + repo is huge, and trying to map and sync it all will take + an enormous amount of resources. Instead, only map the + section of the repo that you intend to work on. For + example, there is the smpng project tree at + //depot/projects/smpng. A mapping + for this might look like: + + //depot/projects/smpng/... //client/... + + The ... should be taken literally. + It is a Perforce idiom for + saying this directory and all files and directories + below it. + + A Perforce view can contain multiple + mappings. Say you want to map in both the SMPng tree and + the NFS tree. Your View might look like: - - This is the name of the client spec. It can be anything - you want, but it must be unique within the - Perforce server. A naming - convention that is commonly used is - username_machinename, - which makes it easy to identify clients when browsing them. - A default name will be filled in that is just the machine - name. - - - - - Description: - - - This can contain a simple text description to help - identify the client. - - - - - Root: - - - This is the local directory that will serve as the root - directory of all the files in the client mapping. This should - be a unique location in your filesystem that does not overlap - with other files or Perforce - clients. - - - - - Options: - - - Most of the default options are fine, though it is - usually a good idea to make sure that the - and options - are present and do not have a no prefix on - them. Details about each option are in the - Perforce docs. - - - - - LineEnd: - - - This handles CR-LF conversions and should be left to the - default unless you have special needs for it. - - - - - View: - - - This is where the server-to-local file mappings go. The - default is - - //depot/... //client/... - - This will map the entire - Perforce repository to the - Root directory of your - client. DO NOT USE THIS DEFAULT! The - &os; repo is huge, and trying to map and sync it all will - take an enormous amount of resources. Instead, only map the - section of the repo that you intend to work on. For - example, there is the smpng project tree at //depot/projects/smpng. A - mapping for this might look like: - - //depot/projects/smpng/... //client/... - - The ... should be taken literally. It - is a Perforce idiom for saying - this directory and all files and directories below - it. - - A Perforce view can contain multiple - mappings. Say you want to map in both the SMPng tree and - the NFS tree. Your - View might look like: - - //depot/projects/smpng/... //client/smpng/... + //depot/projects/smpng/... //client/smpng/... //depot/projects/nfs/... //client/nfs/... - Remember that the client is - the name of the client that was specified in the - Client section, but in the - View it also resolves to the directory - that was specified in the Root - section. - - Also note that the same file or directory cannot be - mapped multiple times in a single view. The following is - illegal and will produce undefined results: + Remember that the client is + the name of the client that was specified in the + Client section, but in the + View it also resolves to the directory + that was specified in the Root + section. + + Also note that the same file or directory cannot be + mapped multiple times in a single view. The following is + illegal and will produce undefined results: - //depot/projects/smpng/... //client/smpng-foo/... + //depot/projects/smpng/... //client/smpng-foo/... //depot/projects/smpng/... //client/smpng-bar/... - Views are a tricky part of the learning experience with - Perforce, so do not be afraid to - ask questions. - - - - - Existing clients can be listed via p4 - clients. They can be viewed without being - modified via p4 client -o - clientname. - - Whenever you are interacting with files in - Perforce, the P4CLIENT - environment variable must be set to the name of the client that - you are using, like so: - - &prompt.user; export P4CLIENT=myclientname - - Note that client mappings in the repository are not exclusive; - multiple clients can map in the same part of the repository. This - allows multiple people to access and modify the same parts of the - repository, allowing a team of people to work together on the same - code. - - - - Syncing - - Once you have a client specification defined and the - P4CLIENT variable set, the next step is to pull the - files for that client down to your local machine. This is done - with p4 sync, which instructs - Perforce to synchronize the local files - in your client with the repository. The first time it runs, it - will download all of the files. Subsequent runs will only - download files that have changed since the previous run. This - allows you to stay in sync with others whom you might be working - with. - - Sync operations only work on files that the - Perforce server knows has changed. If - you change or delete a file locally without informing the server, - doing a sync will not bring it back. However, doing a p4 - sync -f will unconditionally sync all files, regardless - of their state. This is useful for resolving problems where you - think that your tree might be corrupt. - - You can sync a subset of your tree or client by specifying a - relative path to the sync command. For example, to only sync the - ufs directory of the - smpng project, you might do the - following: + Views are a tricky part of the learning experience + with Perforce, so do not be + afraid to ask questions. + + + + + Existing clients can be listed via p4 + clients. They can be viewed without being modified + via p4 client -o + clientname. + + Whenever you are interacting with files in + Perforce, the P4CLIENT + environment variable must be set to the name of the client that + you are using, like so: + + &prompt.user; export P4CLIENT=myclientname + + Note that client mappings in the repository are not + exclusive; multiple clients can map in the same part of the + repository. This allows multiple people to access and modify + the same parts of the repository, allowing a team of people to + work together on the same code. + + + + Syncing + + Once you have a client specification defined and the + P4CLIENT variable set, the next step is to pull + the files for that client down to your local machine. This is + done with p4 sync, which instructs + Perforce to synchronize the local + files in your client with the repository. The first time it + runs, it will download all of the files. Subsequent runs will + only download files that have changed since the previous run. + This allows you to stay in sync with others whom you might be + working with. + + Sync operations only work on files that the + Perforce server knows has changed. + If you change or delete a file locally without informing the + server, doing a sync will not bring it back. However, doing a + p4 sync -f will unconditionally sync all + files, regardless of their state. This is useful for resolving + problems where you think that your tree might be corrupt. + + You can sync a subset of your tree or client by specifying a + relative path to the sync command. For example, to only sync + the ufs directory of the + smpng project, you might do the + following: - &prompt.user; cd projectroot/smpng + &prompt.user; cd projectroot/smpng &prompt.user; p4 sync src/sys/ufs/... - Specifying a local relative path works for many other - p4 commands. - - - - Branches - - One of the strongest features of - Perforce is branching. Branches are - very cheap to create, and moving changes between related branches - is very easy (as will be explained later). Branches also allow - you to do very experimental work in a sandbox-like environment, - without having to worry about colliding with others or - destabilizing the main tree. They also provide insulation against - mistakes while learning the Perforce - system. With all of these benefits, it makes sense for each - project to have its own branch, and we strongly encourage that - with &os;. Frequent submits of changes to the server are also - encouraged. - - Similar to Subversion, the - Perforce repository (the - depot) is a single flat tree. Every file, whether - a unique creation or a derivative from a branch, is accessible via - a simple path under the server //depot directory. When you create a - branch, all you are doing is creating a new path under the - //depot. This is in sharp - contrast to systems like CVS, where each branch lives in the same - path as its parent. With Perforce, the - server tracks the relationship between the files in the parent and - child, but the files themselves live under their own paths. - - The first step to creating a branch is to create a branch - specification. This is similar to a client specification, but is - created via the command p4 branch - branchname. - - The following important fields are explained: - - - - Branch - - - The name of the branch. It can be any name, but must be - unique within the repository. The common convention in &os; - is to use - username_projectname. - - - - - Description - - - This can hold a simple text description to describe the - branch. - - - - - View + Specifying a local relative path works for many other + p4 commands. + + + + Branches + + One of the strongest features of + Perforce is branching. Branches are + very cheap to create, and moving changes between related + branches is very easy (as will be explained later). Branches + also allow you to do very experimental work in a sandbox-like + environment, without having to worry about colliding with others + or destabilizing the main tree. They also provide insulation + against mistakes while learning the + Perforce system. With all of these + benefits, it makes sense for each project to have its own + branch, and we strongly encourage that with &os;. Frequent + submits of changes to the server are also encouraged. + + Similar to Subversion, the + Perforce repository (the + depot) is a single flat tree. Every file, + whether a unique creation or a derivative from a branch, is + accessible via a simple path under the server + //depot directory. When you create a + branch, all you are doing is creating a new path under the + //depot. This is in sharp contrast to + systems like CVS, where each branch lives in the same path as + its parent. With Perforce, the + server tracks the relationship between the files in the parent + and child, but the files themselves live under their own + paths. + + The first step to creating a branch is to create a branch + specification. This is similar to a client specification, but + is created via the command p4 branch + branchname. + + The following important fields are explained: + + + + Branch + + + The name of the branch. It can be any name, but must + be unique within the repository. The common convention in + &os; is to use + username_projectname. + + + + + Description + + + This can hold a simple text description to describe + the branch. + + + + + View + + + This is the branch mapping. Instead of mapping from + the depot to the local machine like a client map, it maps + between the branch parent and branch child in the depot. + For example, you might want to create a branch of the + smpng project. The mapping might look like: + + //depot/projects/smpng/... //depot/projects/my-super-smpng/... + + Or, you might want to create a brand new branch off of + the stock &os; sources: + + //depot/vendor/freebsd/... //depot/projects/my-new-project/... + + This will map the &os; HEAD tree to your new + branch. + + + + + Creating the branch spec only saves the spec itself in the + server, it does not modify the depot or change any files. The + directory that you specified in the branch is empty on the + server until you populate it. + + To populate your branch, first edit your client with + p4 client and make sure that the branch + directory is mapped in your client. You might need to add a + View line like: + + //depot/projects/my-new-project/... //myclient/my-new-project/... + + The next step is to run p4 integrate, as + described in the next section. + + + + Integrations + + Integration is the term used by + Perforce to describe the action of + moving changes from one part of the depot to another. It is + most commonly done in conjunction with creating and maintaining + branches. An integration is done when you want to initially + populate a branch, and it is done when you want to move + subsequent changes in the branch from the parent to the child, + or from the child to the parent. A common example of this is + periodically integrating changes from the vendor &os; tree to + your child branch tree, allowing you to keep up to date with + changes in the &os; tree. The + Perforce server tracks the changes in + each tree and knows when there are changes that can be + integrated from one tree to another. + + The common way to do an integration is with the following + command: + + &prompt.user; p4 integrate -b branchname + + branchname is the name given to a + branch spec, as discussed in the previous section. This command + will instruct Perforce to look for + changes in the branch parent that are not yet in the child. + From those changes it will prepare a list of diffs to move. If + the integration is being done for the first time on a branch + (for example doing an initial population operation), then the + parent files will simply be copied to the child location on the + local machine. + + Once the integration operation is done, you must run + p4 resolve to accept the changes and resolve + possible conflicts. Conflicts can arise from overlapping + changes that happened in both the parent and child copy of a + file. Usually, however, there are no conflicts, and + Perforce can quickly figure out how + to merge the changes together. Use the following commands to do + a resolve operation: - - This is the branch mapping. Instead of mapping from the - depot to the local machine like a client map, it maps between - the branch parent and branch child in the depot. For example, - you might want to create a branch of the smpng project. The - mapping might look like: - - //depot/projects/smpng/... //depot/projects/my-super-smpng/... - - Or, you might want to create a brand new branch off of - the stock &os; sources: - - //depot/vendor/freebsd/... //depot/projects/my-new-project/... - - This will map the &os; HEAD tree to your new - branch. - - - - - Creating the branch spec only saves the spec itself in the - server, it does not modify the depot or change any files. The - directory that you specified in the branch is empty on the server - until you populate it. - - To populate your branch, first edit your client with - p4 client and make sure that the branch - directory is mapped in your client. You might need to add a - View line like: - - //depot/projects/my-new-project/... //myclient/my-new-project/... - - The next step is to run p4 integrate, as - described in the next section. - - - - Integrations - - Integration is the term used by - Perforce to describe the action of - moving changes from one part of the depot to another. It is most - commonly done in conjunction with creating and maintaining - branches. An integration is done when you want to initially - populate a branch, and it is done when you want to move subsequent - changes in the branch from the parent to the child, or from the - child to the parent. A common example of this is periodically - integrating changes from the vendor &os; tree to your child branch - tree, allowing you to keep up to date with changes in the &os; - tree. The Perforce server tracks the - changes in each tree and knows when there are changes that can be - integrated from one tree to another. - - The common way to do an integration is with the following - command: - - &prompt.user; p4 integrate -b branchname - - branchname is the name given to a - branch spec, as discussed in the previous section. This command - will instruct Perforce to look for - changes in the branch parent that are not yet in the child. From - those changes it will prepare a list of diffs to move. If the - integration is being done for the first time on a branch (for example - doing an initial population operation), then the parent files will - simply be copied to the child location on the local - machine. - - Once the integration operation is done, you must run - p4 resolve to accept the changes and resolve - possible conflicts. Conflicts can arise from overlapping changes - that happened in both the parent and child copy of a file. - Usually, however, there are no conflicts, and - Perforce can quickly figure out how to - merge the changes together. Use the following commands to do a - resolve operation: - - &prompt.user; p4 resolve -as + &prompt.user; p4 resolve -as &prompt.user; p4 resolve - The first invocation will instruct - Perforce to automatically merge the - changes together and accept files that have no conflicts. The - second invocation will allow you to inspect each file that has a - possible conflict and resolve it by hand if needed. - - Once all of the integrated files have been resolved, they need - to be committed back to the repository. This is done via - p4 submit, explained in the next - section. - - - - Submit - - Changes that are made locally should be committed back to the - Perforce server for safe keeping and so - that others can access them. This is done via p4 - submit. When you run this command, it will open - up a submit template in an editor. &os; has a custom template, - and the important fields are described below: + The first invocation will instruct + Perforce to automatically merge the + changes together and accept files that have no conflicts. The + second invocation will allow you to inspect each file that has a + possible conflict and resolve it by hand if needed. + + Once all of the integrated files have been resolved, they + need to be committed back to the repository. This is done via + p4 submit, explained in the next + section. + + + + Submit + + Changes that are made locally should be committed back to + the Perforce server for safe keeping + and so that others can access them. This is done via + p4 submit. When you run this command, it + will open up a submit template in an editor. &os; has a custom + template, and the important fields are described below: - Description: + Description: <enter description here> PR: Submitted by: @@ -471,394 +497,414 @@ Obtained from: MFP4 after: - It is good practice to provide at least 2-3 sentences that - describe what the changes are that you are submitting. You should - say what the change does, why it was done that way or what - problem is solves, and what APIs it might change or other side - effects it might have. This text should replace the - <enter description here> line in the template. - You should wrap your lines and start each line with a TAB. The - tags below it are &os;-specific and can be removed if not - needed. - - Files: - - This is automatically populated with all of the files in your - client that were marked in the add, delete, integrate, or edit - states on the server. It is always a very good idea to review - this list and remove files that might not be ready yet. - - Once you save the editor session, the submit will happen to - the server. This also means that the local copies of the - submitted files will be copied back to the server. If anything - goes wrong during this process, the submit will be aborted, and - you will be notified that the submit has been turned into a - changelist that must be corrected and re-submitted. Submits are - atomic, so if one file fails, the entire submit is aborted. - - Submits cannot be reverted, but they can be aborted while in - the editor by exiting the editor without changing the - Description text. - Perforce will complain about this the - first time you do it and will put you back in the editor. Exiting - the editor the second time will abort the operation. Reverting a - submitted change is very difficult and is best handled on a - case-by-case basis. - - - - Editing - - The state of each file in the client is tracked and saved on - the server. In order to avoid collisions from multiple people - working on the same file at once, - Perforce tracks which files are opened - for edit, and uses this to help with submit, sync, and integration - operations later on. - - To open a file for editing, use p4 edit - like so: - - &prompt.user; p4 edit filename - - This marks the file on the server as being in the edit state, - which then allows it to be submitted after changes are made, or - marks it for special handling when doing an integration or sync - operation. Note that editing is not exclusive in - Perforce. Multiple people can have the - same file in the edit state (you will be informed of others when - you run edit), and you can submit - your changes even when others are still editing the file. - - When someone else submits a change to a file that you are - editing, you will need to resolve his changes with yours before - your submit will succeed. The easiest way to do this is to either - run a p4 sync or p4 submit - and let it fail with the conflict, then run p4 - resolve to manually resolve and accept his changes into - your copy, then run p4 submit to commit your - changes to the repository. - - If you have a file open for edit and you want to throw away - your changes and revert it to its original state, run - p4 revert like so: - - &prompt.user; p4 revert filename - - This resyncs the file to the contents of the server, and - removes the edit attribute from the server. Any local changes *** DIFF OUTPUT TRUNCATED AT 1000 LINES ***