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. :)
[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)
Password: your-password
[parrt@nexus test]$ p4 edit A.java //depot/test/A.java#2 - opened for editand 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.nfsThis 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.javaDoing 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.