Presentation from Qwilt at the Tel Aviv Merge World Tour - Qwilt P4 Conference

1. Perforce Usage @
Qwilt
Oren Shemesh, July 2013

2. § Who we are
§ What we store in Perforce
§ How we use Perforce
§ Why we like it
§ Some advice
2
Agenda

3. § Qwilt is a start-up building a Transparent Video
Caching platform
- A Linux-based appliance, SW only
§ Founded 3 years ago
§ Currently developing a single product
- Already in the market
§ ~40 Developers
§ Not a ‘cutting edge’ customer
- Wish we had more time to explore the benefits of
new P4 features and tools
3
Who we are

4. § Short answer: Everything
§ Source Code
- Product code
- Test code
- Development environment code
- External code
- Any code that lives longer than 1 day
§ Large data files (Mainly used for testing)
§ SW Images
§ Spec/Design Documents
§ In general, Every file that needs sharing or control
4
What we Store in Perforce
Version
Everything

5. § Three servers, separate mainly due to different
storage requirements (e.g. backup)
- main: Source code
§ Tons of small files, High submit rate
- big: Large data files, Low submit rate
- release: Released components/products (Internal
and External)
§ Few very large files, Low submit rate
§ To save disk space, old/irrelevant builds are
obliterated (Can always be reconstructed from
source if needed)
5
P4 Servers @ Qwilt

6. § ~100 Code bases
- Some very small (10 files per branch), Some very
large (100K files per branch)
§ Most active code base (Main product code,
~10K files) already has ~200 branches
6
Some Stats about Server main

7. § Triggers allow us to enforce anything we can
think of:
- Every submit must be limited to a single branch
- On some codebases, every submit must include a
defect number
- Prevent case-clashing in file names
- No <tab> characters in python files
- All workspace definitions must follow certain rules
§ Some of our triggers are configured by special
files kept as part of the codebase/branch
Qwilt Confidential & Proprietary 7
Triggers: A Dictator’s Tool of Choice

8. § Products are composed of multiple components
§ Each product/component:
- Is developed in a separate code base on the
main server
- May use other components from the release
server
- Is released to the release server
8
Component-Based Development
//main:
Code
//release:
SW images
build

9. § New employees get the basics in ~10 minutes
§ Developers find it a very friendly tool
- Changelists help you organize your work and
remember what you are working on
- GUI is very friendly and versatile
- Multiple tools for viewing history
- P4 actually makes you WANT to use it !
§ Advanced usage is intuitive
- Branch model: No hidden dimensions
- Merging is automatic, yet the developer has total
control
Qwilt Confidential & Proprietary 9
Why we Like Perforce: Easy to Use

10. § One administrator (me), dedicating <5% of my
time for:
- Setting up the servers
- Writing/maintaining backup scripts, monitoring
backup jobs
- Writing/maintaining triggers as needed
- Maintaining users, groups, permissions
- Installing license files
- Upgrading the server
- Writing/maintaining initial tutorial for new workers
Qwilt Confidential & Proprietary 10
Why we Like Perforce: Easy to Manage

11. § Based on a simple command-line interface
§ GUI helps you see what CLI commands are
executed by various actions
§ Client libraries for multiple languages are freely
available
§ Writing scripts that interface with Perforce is
easy
Qwilt Confidential & Proprietary 11
Why we Like Perforce: Easy to Automate

12. § Use the mainline model
- ‘main’ is the branch that accumulates all changes
§ The “Tofu Scale” is a method to organize and
visualize your branch tree
Qwilt Confidential & Proprietary 12
Tip #1: The Mainline Model and Tofu Scale
main
2.0
2.0.1
Project X
Private y
2.0.2
soft
firm

13. § Control the flow of change: Plan your branch
tree, anticipate changes
- Perforce Streams help you enforce the flow of
change
Qwilt Confidential & Proprietary 13
Tip #1: The Mainline Model and Tofu Scale

14. § Use project and private branches to separate
work that can be done separately
- Risk management: Lets you decide what features
go into the release based on their stability
§ Branches are easy. Encourage developers to
use them freely:
- Project branches allow a small team to work
without being affected by noise, and without
having to worry about other teams
- Private branches allow a developer to submit
even code that breaks the branch
Qwilt Confidential & Proprietary 14
Tip #2: Use Plenty of Branches !

15. § Make the developers comfortable with having
more than one workspace
- Allows developing two separate features/bug-
fixes on the same branch
§ Simple, yet developers are sometimes blind to
this possibility
Qwilt Confidential & Proprietary 15
Tip #3: Use Workspaces

16. Qwilt Confidential & Proprietary 16
Thank You for Listening !