Perforce Revision Control System Lab

Perforce Revision Control System Lab

This worksheet helps you figure out how perforce works with multiple programmers. Team members should work together on this lab, but of course logged in to their own accounts on different computers. This lab is designed to show you how to work together. :)

  1. Set up your client. Set your .bash_profile and /home/user/depot/.p4 file according to the lecture notes. Since you haven't set up a password yet, either don't add that line or leave it empty.
  2. Verify that you can connect to the server. You should see (with parrt replaced with your user):
    [parrt@nexus depot]$ p4 info
    User name: parrt
    Client name: parrt.nfs
    Client host: nexus.cs.usfca.edu
    Client root: /home/parrt/depot
    Current directory: /home/parrt/depot
    Client address: 138.202.170.4:58303
    Server address: dweller.cs.usfca.edu:1666
    Server root: /var/local/perforce
    Server date: 2003/10/21 13:21:54 -0700 PDT
    Server version: P4D/LINUX24X86/2003.1/46260 (2003/07/03)
    Server license: Univ. of San Francisco 35 users (expires 2004/08/11) 
    
  3. Make sure you set your password via p4 user. In the editor, add the following line:
    Password: your-password
    
  4. Your /home/user/depot dir reflects the state of the depot location //depot/cs601/groupN. Have each team member create a different file; perhaps A.java and B.java on separate user accounts. Each member submits their file. Then each you do a sync. It should pull in the other person's file.
  5. Edit your partner's file and submit. Have the original author of the file do a sync on their machine to verify that they get the updated file. Do a p4 changes to see what changes have been made.
  6. Both of you should now see what happens when you simultaneously change a file. Both of you do a p4 edit A.java. You should see one person like this:
    [parrt@nexus test]$ p4 edit A.java
    //depot/test/A.java#2 - opened for edit
    
    and another like this:
    ~/USF/depot/test $ p4 edit A.java
    //depot/test/A.java#2 - opened for edit
    ... //depot/test/A.java - also opened by parrt@parrt.nfs
    
    This means that somebody is alreadying editing it and whoever submits their changes last will have to do a resolve. If the first person changes A.java to:
    /** A */
    public class A {
            int i;
    }
    
    and submits, perforce will not complain:
    Change 9 created with 1 open file(s).
    Submitting change 9.
    Locking 1 files ...
    edit //depot/test/A.java#3
    Change 9 submitted.
    
    However, the other user changes A.java to
    /** A is a test file */
    public class A {
    }
    
    Upon submit they will see:
    Change 10 created with 1 open file(s).
    Submitting change 10.
    //depot/test/A.java - must resolve before submitting
    //depot/test/A.java - must resolve #3
    Out of date files must be resolved or reverted.
    Submit failed -- fix problems above then use 'p4 submit -c 10'.
    
    There are two different changes to be made to the original A.java. You are the second to submit so must do the resolve. Type p4 resolve to see what perforce knows about the changes:
    ~/USF/depot/test $ p4 resolve
    /Users/parrt/USF/depot/test/A.java - merging //depot/test/A.java#3
    Diff chunks: 1 yours + 1 theirs + 0 both + 0 conflicting
    Accept(a) Edit(e) Diff(d) Merge (m) Skip(s) Help(?) am: 
    
    The am means accept merged file. Since no chunks are conflicting (i.e., on the same line), it is ok to accept the merge. perforce will respond:
    //parrt.localhost/test/A.java - merge from //depot/test/A.java
    
    Doing a submit will now work:
    ~/USF/depot/test $ p4 submit -c 10
    Submitting change 10.
    Locking 1 files ...
    edit //depot/test/A.java#4
    Change 10 submitted.
    
    Finally, have the original modifier person sync to get the merged copy of the file. Now both people will see:
    ~/USF/depot/test $ cat A.java
    /** A is a test file */
    public class A {
            int i;
    }
    
    In general you should be VERY careful modifying the same file as your partner. You should agree on boundaries.