#

John LoVersoSoftware Archeologist

Moving 1000 Users and 100 Branches Into Streams

#

• Background• Component-Based Development• Migrating to Streams• Remaining Challenges• Questions

Overview

#

• We are a 3000+ person company dedicated to accelerating the pace of engineering and science

• We have ~90 products based upon our core platforms– MATLAB – The Language of Technical Computing– Simulink – Simulation and Model-Based Design

MathWorks

#

• Unified code base from which full product family is released twice a year

• Integrating changes from ~1000 developers• Managing an almost 1 million file code base

Technical Challenges

#

Component-Based Development

#

• Components have meta data (XML files) that describe their key characteristics– what portions of the SCM namespace they own

• A mixture of directories and files

– what components they depend on

• Each source file is owned by exactly one component– Some directories consist of files from different

components

Components

#

• Each branch is composed of a collection of components– We call this collection the CTB

(or “Components To Build”) list

• Branches are hierarchical– Children have a proper subset of their parent’s

components

Branches and Components

#

• Wide-open client views– Eliminates need to manage client views– Eliminates constraints with adding/moving files

• Restricted branch views– Computed from the component metadata– Minimizes integration records in server database– Makes merging fast

Classic Perforce – Initial Strategy

#

Stale Files• Branch views don’t define the “width” of branches

– They define mappings between related codelines– With a wide-open client view, stale files remain visible

Branch Width

Mapping Width

“Dead wood”

#

• Narrow client views– Makes certain workflows more cumbersome

• Adding a new component• Expanding the CTB list to include an existing component• Changing the files a component owns (its “shape”)

Classic Perforce - Alternate Strategy

#

• Our strategies for managing client and branch view were not meeting our needs– Initial efforts worked for small, relatively static branches– Larger more dynamic branches became a nightmare to

manage

Hitting the Wall

#

Migrating to Streams

#

• Streams replace separate client and branch views with a unified stream view

• Streams are true hierarchical branches• Their evolution is recorded as part of depot history

Virtues of Streams

#

• Avoid the need for developers to know about or manipulate client and/or branch views

• Make componentization and refactoring easier• Keep workflows simple and robust• Use Perforce efficiently so as to avoid

performance and scalability issues

Design Goals

#

• Any change to a stream immediately affects all subsequent operations involving the implied client or branch views

• So a developer who changes a stream’s shape can affect the work-in-progress of all other developers working in that stream, even if they haven’t re-synced their workspace

Not So Fast

#

• Wide-open client views• The ability to widen a branch (stream) from below• Stream (shape) changes to be atomic with content

changes

Additional Design Goals

#

Virtual Streams as a Filter

#

• Client uses real stream– Wide open view

“share …”

• Each real stream has acorresponding virtualstream– Holds the limited

component-derived view

Our Approach

#

• A broker wrapper dynamically switches the client to the virtual stream when running commands that should work in a limited view– p4 sync, flush, update– p4 merge, copy, integrate, populate

• Transparent for both CLI and P4V usage

Solution Part 1: P4 Broker

#

• User types:p4 sync

• Broker script rewrites to:p4 client –f –s –S //mw/Branch~virtual

p4 sync

p4 client –f –s –S //mw/Branch

Example Rewrite of Sync

#

• User types:p4 sync @12345

• Broker script rewrites to:p4 client –f –s –S //mw/Branch~virtual

p4 sync @12345

p4 client –f –s –S //mw/Branch

Time Inconsistent Shape

#

• User types:p4 sync @12345

• Broker script rewrites to:p4 client –f –s –S //mw/Branch~virtual@12345

p4 sync @12345

p4 client –f –s –S //mw/Branch

Sync with StreamAtChange

#

• The shape of the virtual stream is updated on submit– via a change-content trigger– only when the submission contains metadata changes

• Validates user changes to component metadata• Virtually no workflow changes

Solution Part 2: P4 Trigger

#

• Provides a wide client/narrow branch paradigm without the shortcomings

• No need for developers to know about or manipulate client or branch or stream views

• Sophistication occurs in the re-computation of the stream shape at submit time

Key Benefits

#

• Developed automated tooling for merging– Temporary virtual stream to bound merge down– Wide open stream for merge up

• Insulates users from the complexities of merging with time-varying component definitions (shapes)

Merges Between Streams

#

Operational Considerations

#

• Test Infrastructure that mirrors production• Every night at midnight, the test server is rebuild

from the backup of production• Allows us to test any sort of approach we want

with real live data without impacting production

P4 Test Server Infrastructure

#

• Couldn’t just “p4 populate” the streams– Too much change inflight

• Used deep renamesPreserved revision historyEnabled incremental migration– Undocumented command– Experienced random loss of integration records

Migrating Branches to Streams

#

Remaining Challenges

#

Merge Problems

#

• Rename is powerful, but has many merge issues– Renames that cross view boundaries

• Old name or new name is out of the destination view

– Complex sequences of changes cannot be merged atomically• Rename followed by re-add of old name

– Incorrect automatic merge results

• Unnecessary manual resolves

Merge Problems

##

Thank you!John LoVerso

john.loverso@mathworks.com

The Team:

Marc Ullman

Michael Mirman

Karishma Panjwani

Raghuvir Leelasagar