When developers build software, they're able to keep track of all the different versions and all the components they use with software configuration management (SCM) systems. One of the more popular SCM products is Perforce.
Authored by Perforce's own VP of product technology, Practical Perforce is the ideal complement to the existing product manual, focusing less on the 'how" and more on the "why" and "when." The book is not only a helpful introduction to Perforce, it's an enlightening resource for those already familiar with this versatile SCM product. Whether you're a programmer, product manager, or build engineer, you stand to benefit from the many insider tips and ideas presented in this convenient guide.
Practical Perforce is divided into two main parts. Part I offers a whirlwind technical tour, complete with careful descriptions of basic and advanced Perforce commands designed to give you a baseline knowledge. Part II describes the big picture-using Perforce in a collaborative software development. It outlines recommended best practices and quickly shows how to implement them with the Perforce operations introduced in Part I. Throughout the book, you'll learn how to maximize Perforce so it completes tasks like these in the most efficient manner possible:
Keep track of changes as you conduct concurrent parallel work on files
Generate reports on who did what when
Compare, merge and branch files
Store files and file configurations
Restore lost bug fixes
Recognizing the pitfalls and practices of an SCM system like Perforce is absolutely essential to producing good software. Now, with Practical Perforce, you have the edge you need to ensure success.
Table of contents
1. Files in the Depot
- 1.1. The Perforce Filespec Syntax
1.2. Browsing Depot Files
- 1.2.1. Navigating the file tree
- 1.2.2. Listing directories
- 1.2.3. Listing directory history
- 1.2.4. What’s in a changelist?
- 1.2.5. Listing files and file information
- 1.2.6. Finding files
- 1.2.7. Perusing file history and file origins
- 1.2.8. Perusing file content
- 1.2.9. Saving informal copies of files
- 1.2.10. Comparing depot files
- 1.2.11. Comparing depot directories
- 1.3. File Types at a Glance
2. Working with Files
- 2.1. An Overview
- 2.2. Creating A Workspace
2.3. Synchronizing a Workspace
- 2.3.1. Listing unsynchronized files
- 2.3.2. Synchronizing the entire workspace
- 2.3.3. Synchronizing in bits and pieces
- 2.3.4. When did I last synchronize?
- 2.3.5. What’s new in the depot?
- 2.3.6. Synchronizing with older revisions
- 2.3.7. Listing files in your workspace
- 2.3.8. Detecting missing workspace files
- 2.3.9. Replacing missing files
- 2.3.10. Detecting files that didn’t come from the depot
- 2.4. Local Syntax, Wildcard Expansion, and Special Characters
2.5. Working with Local Files
- 2.5.1. Opening files for editing
- 2.5.2. Which files am I working on?
- 2.5.3. Who’s working on these files?
- 2.5.4. Which files did I change?
- 2.5.5. Adding new files to the depot
- 2.5.6. Adding an entire directory tree of files
- 2.5.7. Deleting depot files
- 2.5.8. Cloning depot files and directories
- 2.5.9. Modifying files as you clone them
- 2.5.10. Renaming files and directories
- 2.5.11. Replacing and swapping file content
- 2.5.12. Locking files
- 2.5.13. Designating file types
- 2.5.14. Changing the type of existing files
- 2.5.15. Opening files after the fact
- 2.5.16. Reverting files
2.6. Working with Pending Changelists and Submitting Files
- 2.6.1. Submitting a pending changelist
- 2.6.2. Preventing unchanged files from being submitted
- 2.6.3. Creating additional changelists
- 2.6.4. Do I have more than One pending changelist?
- 2.6.5. Moving files from one changelist to another
- 2.6.6. What’s in this changelist?
- 2.6.7. Submitting a numbered pending changelist
- 2.6.8. Getting rid of empty changelists
- 2.6.9. Submitting a Subset of opened files
- 2.6.10. When submit fails
- 2.6.11. Resolving files
- 2.6.12. Listing unresolved files
- 2.7. Removing and Restoring Files
- 2.8. Useful Recipes
3. Resolving and Merging Files
3.1. Resolving: When, What, and How
- 3.1.1. Are You in Sync?
- 3.1.2. Which files need resolving?
- 3.1.3. Resolving files automatically
- 3.1.4. “Yours,” “theirs,” and “base”
- 3.1.5. Resolving files by copying theirs into yours
- 3.1.6. Resolving files by ignoring theirs
- 3.1.7. Resolving files by merging theirs into yours
- 3.1.8. Resolving files interactively
- 3.1.9. Perforce doesn’t merge binary files
- 3.1.10. What’s been resolved, and how?
- 3.2. How Perforce Merges Text Files
3.3. Reconciling Structural Changes
- 3.3.1. Someone adds the files you were going to add
- 3.3.2. Someone deletes the files you were going to delete
- 3.3.3. Someone renames the files you were editing
- 3.3.4. Someone moves the files you were editing
- 3.3.5. Someone combines the files you were editing with other files
- 3.3.6. Someone deletes the files you were editing
- 3.3.7. Someone edits the files you were going to delete
- 3.3.8. Someone edits the files you planned to rename or move
- 3.3.9. Reconciling file type changes
- 3.4. Tips for Smoother Collaboration
3.5. The Arcana of Merging
- 3.5.1. Forced merging
- 3.5.2. Can you undo or redo a resolve?
- 3.5.3. Can you undo a merge?
- 3.5.4. What happens when you revert files?
- 3.5.5. Backing out changes, revisited
- 3.5.6. Configuring P4 to use P4Merge
- 3.5.7. Configuring an alternate merge tool
- 3.5.8. Merging nontext files
- 3.5.9. Setting P4MERGE
- 3.1. Resolving: When, What, and How
4. Branching and Integration
- 4.1. The Classic Case for A Branch
4.2. Creating Branches
- 4.2.1. Opening files for branching
- 4.2.2. Branching from a point in time
- 4.2.3. Am I branching the right files?
- 4.2.4. Oops, I branched the wrong files!
- 4.2.5. It’s not a branch until the files are submitted
- 4.2.6. Can you undo and redo a branch?
- 4.2.7. Creating really huge branches
- 4.2.8. Working in a New Branch
- 4.2.9. Browsing branch history
- 4.2.10. Comparing branches
4.3. Integrating Changes from Branch to Branch
- 4.3.1. Which Changes Need Integrating?
- 4.3.2. Integrating Changes incrementally
- 4.3.3. Integrations won’t be repeated
- 4.3.4. Which files need resolving ? (And why?)
- 4.3.5. “Yours”, “theirs”, and “base”, revisited
- 4.3.6. Merging the donor file into the target
- 4.3.7. Copying the donor file into the target
- 4.3.8. Ignoring the donor file’s changes
- 4.3.9. Editing files as you’re integrating them
- 4.3.10. Integrating by subdirectory
- 4.3.11. Cherry-picking changes to integrate
- 4.3.12. Integrating all changes at once
- 4.3.13. Which Changes Were Integrated?
- 4.3.14. Don’t break up changelists
- 4.4. Reconciling Structural Changes
4.5. The Arcana of Integration
- 4.5.1. Reconciling Split and Combined Files
- 4.5.2. Integration history can’t be undone
- 4.5.3. Forcing Perforce to Redo an Integration
- 4.5.4. The mechanics of integration
- 4.5.5. What interchanges really tells us
- 4.5.6. Decoding integration history
- 4.5.7. Why does editing matter?
- 4.5.8. The curious syntax of the integrate command
5. Labels and Jobs
- 5.1. Saving Important Configurations
5.2. Using Labels
- 5.2.1. Applying a label to files
- 5.2.2. Referring to labels
- 5.2.3. Which files did I label?
- 5.2.4. Locking a label
- 5.2.5. Do you really need a label?
- 5.2.6. Labeling the current workspace configuration
- 5.2.7. What’s the difference between tag and labelsync?
- 5.2.8. Finding and comparing labels
- 5.2.9. Reusable labels (rolling labels)
- 5.2.10. Archiving rolling labels with unique labels
- 5.2.11. Archiving rolling labels in files
- 5.2.12. Labels have views , too
- 5.2.13. Removing a label
- 5.2.14. Labels, snapshots, and workspaces
- 5.3. Using Jobs
- 5.4. Jobs as Changelist Markers
6. Controlling and Automating Activity
- 6.1. Depot and File Access
- 6.2. Accessing Files in Other Domains
- 6.3. Saving and Restoring Specs
- 6.4. Change Notification and Change Monitoring
- 6.5. Scripting Tips
- 6.6. Behind-the-Scenes Version Control
7. How Software Evolves
- 7.1. The Story of Ace Engineering
7.2. The Mainline Model
- 7.2.1. From ideal world to real world
- 7.2.2. The flow of change
- 7.2.3. Branching from release codelines
- 7.2.4. Branching from development codelines
- 7.2.5. Soft, medium, and firm: the tofu scale
- 7.2.6. A codeline by any other name...
- 7.2.7. One-way codelines
- 7.2.8. Codelines that aren’t codelines
- 7.2.9. Musings on codeline diagrams
- 7.3. Ace Engineering Revisited
- 7.4. Containerizing
8. Basic Codeline Management
- 8.1. Organizing Your Depot
- 8.2. General Care and Feeding of Codelines
- 8.3. Nightly Builds
- 8.4. Is Bug X Fixed in Codeline Y?
9. Release Codelines
9.1. Creating a Release Codeline
- 9.1.1. When should we branch?
- 9.1.2. Who owns the release codeline?
- 9.1.3. Naming a release codeline
- 9.1.4. Which modules should we branch?
- 9.1.5. A branch view for the release codeline
- 9.1.6. The master workspace
- 9.1.7. Are we branching the right files?
- 9.1.8. A label view for the branch point
- 9.1.9. Labeling the branch point
- 9.1.10. Creating the release codeline—really!
- 9.1.11. Branching more files later
- 9.2. Working in a Release Codeline
9.3. Integrating Changes into the Mainline
- 9.3.1. Which changes should be integrated?
- 9.3.2. When should changes be integrated?
- 9.3.3. Who does the integration?
- 9.3.4. A workspace for integrating into MAIN
- 9.3.5. Finding unintegrated changes
- 9.3.6. When it’s okay to integrate changes out of order
- 9.3.7. Integrating a change
- 9.3.8. How much has the mainline changed?
- 9.4. Making a Release
- 9.5. Distributing Releases
- 9.6. Breaking the Rules
- 9.7. Retiring a Release Codeline
- 9.8. Task Branches and Patch Branches
- 9.1. Creating a Release Codeline
10. Development Codelines
10.1. Creating A Development Codeline
- 10.1.1. Why a Development Codeline?
- 10.1.2. What goes on in a development codeline?
- 10.1.3. Who owns the development codeline?
- 10.1.4. Naming the development codeline
- 10.1.5. Which modules should we branch?
- 10.1.6. Why branch static modules ?
- 10.1.7. A branch view for the development codeline
- 10.1.8. Creating a master workspace
- 10.1.9. Branching the development codeline
- 10.2. Working in a Development Codeline
- 10.3. Keeping a Development Codeline Up to Date
- 10.4. Working with Third-Party Software
10.5. Delivering Completed Development Work
- 10.5.1. Merge down, copy up
- 10.5.2. When should development be delivered?
- 10.5.3. Identifying a Point of Completion
- 10.5.4. Which changes should be integrated into the parent?
- 10.5.5. Freezing the parent codeline
- 10.5.6. Which Workspace?
- 10.5.7. Preparing a change description
- 10.5.8. Normalizing the branch view
- 10.5.9. Integrating into the parent codeline
- 10.5.10. Integrating neglected files
- 10.5.11. Thawing the parent codeline
- 10.5.12. Retiring a development codeline
- 10.6. The Soft Codelines
- 10.1. Creating A Development Codeline
11. Staging Streams and Web Content
- 11.1. Staging Web Content
- 11.2. Visual Content Development
- 11.3. Bug Fixes and Staging Streams
- 11.4. Major Web Development
- A. Setting Up a Perforce Test Environment
- B. Perforce Terminology and P4 Commands
- C. Bibliography
- About the Author
- About the Author
- Title: Practical Perforce
- Release date: November 2005
- Publisher(s): O'Reilly Media, Inc.
- ISBN: 9780596101855
You might also like
Site Reliability Engineering
The overwhelming majority of a software system’s lifespan is spent in use, not in design or …
Head First Design Patterns, 2nd Edition
You know you don’t want to reinvent the wheel, so you look to design patterns—the lessons …
Software Engineering at Google
Today, software engineers need to know not only how to program effectively but also how to …
Fundamentals of Software Architecture
Salary surveys worldwide regularly place software architect in the top 10 best jobs, yet no real …