Outsmarting Merge Edge Cases in Component Based Design

Outsmarting Merge Edge Cases in Component Based DevelopmentMike HobbsSoftware Engineer

2

Overview

Background Edge Cases, Pitfalls, and Solutions Conclusion / Q&A

Background

4

Background – MathWorks

We are a 3500+ 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

5

Background - Definitions

Product• MATLAB• Parallel Computing Toolbox• Signal Processing Toolbox

Component• Set of strongly-related files

6

Background - Componentization

~90 products• 5,000+ components, acyclical dependencies• 100,000s of tests and test points• ~36 hours to build and test from the ground up• Managing an over 1 million file code base

Benefits of componentization• Develop in isolation• Identify problems ahead of time• Run only a subset of building and testing

7

Background – Solution Chosen

Single stream per product, mostly• //mw/Bparallel• CTB (“Components to Build”) list, can change• Virtual stream enforcing a view

How to manage getting changes from one stream to another?• Tools (What I work on, automatically merging between streams)

More background: “Moving 1000 Users and 100 Branches Into Streams” – John LoVerso, MERGE 2014

8

Background - Architectural Issues

Renames with regards to crossing thestream view boundary

Submitting both a delete and an add ontothe same filename

Filename-based versus file object-based source control system

9

Background – Filename / File Object

Filename• //mw/productA/file1• //mw/productA/file2

10

Background – Filename / File Object

Filename• //mw/productA/file1• //mw/productA/file2

File Object• p4 add file1• p4 submit

Edge Cases

12

Edge Cases – Complex Merge

What is it?• Multiple changes to merge to a destination• Cannot be represented in one single change

Classic example Easy solution, no?

• “Just merge the left half first.” Can’t ask the developer to manually apply the solution to

each issue we find

13


How do you identify one?• First pitfall: Problem definition

Incorrect: Counting endpoints• Correct in many cases (95% or so)• False positives and false negatives

14



Incorrect: Set of changes that cannotbe represented in just one change• How do you know you are correct?

15



Correct: Identify the actual, big-ticket item• For us, this was the fact that people were renaming files often• Much easier to identify “filenames which need both a delete, and then an

add applied to them” (i.e. complex merge on filename A)

16


How do you resolve one?• Second pitfall: Merging at an earlier change• Third pitfall: Asking the user to do it

Incorrect: Complex merge identified atc123456, so run the command at c123455• Or at c123000, and then at c123100,

and then at c123150, and then…• Manually resolve!

17


How do you resolve one?• Second pitfall: Merging at an earlier change• Third pitfall: Asking the user to do it

Correct: Automatically submit

18

Edge Cases – Deadwood

What is it?• Stream has fileA in view• Stream CTB changes, fileA no longer in view• fileA continues to exist, no changes are received

Files in view

“Dead wood” Files out of view

19


Why is it bad?

Files in view


20


First pitfall: Leave it alone

Files in view


21


Second pitfall: Merge everything from the beginning of time

Files in view


22


Implementation we settled on: Iteratively merge everything in a smaller chunk of changes• Has downsides, manual resolves scheduled when they’re not needed

Files in view


23


Implementation we want to eventually get to: Sparse Branches (John LoVerso’s MERGE 2016 presentation)

Files in view


24

Edge Cases – Renames Across View

Files in view


What is it?• FileA -> FileB -> FileC on the source• FileB is not in view

25

Edge Cases – Rename Across View

What should happen: What actually happens:

26



27



28



29



30


Pitfalls:• Only include the first and last names in view• Only consider one rename, not multiple renames• Add too many things to the view of a virtual stream

31


Solution:• Merge everything in a given range, selectively revert edits and branches• Same solution we use for keeping deadwood relatively managed

32

Edge Cases – Shadowed Delete

What is it?• Delete that does not show up when you merge• Not the head revision• Integration engine thinks it’s done at the move/add

33



34



35



36



37


How to identify it?• Look for deletes not at the head revision

in the range you are merging

How to resolve it?• Merge at a specific revision for the problem file

38


How to identify it?• Look for deletes not at the head revision

in the range you are merging

How to resolve it?• Merge at a specific revision for the problem file

Pitfalls?• Merging multiple times without resolving

Conclusion

40

Conclusion – Lessons Learned

Things to do:• Look at the big picture, solve a problem instead of its symptoms• Ask users to follow a simple, managed workflow• Test everything across releases and decide to upgrade or not

Things not to do:• Assume you’ve found all cases of a problem• Assume Perforce behavior will stay the same

41

Conclusion – What We’d Like

Source control on an object-by-object basis• Reconcile would work in most / all cases• Renames, view, and componentization would be easier to handle and

define by file object content rather than specific filenames Truly sparse streams

• Prevent issues from ever happening, if the files never actually exist on a stream

Questions?Mike HobbsMike dot Hobbs at mathworks dot com

Outsmarting Merge Edge Cases in Component Based Design

Software

Transcript of Outsmarting Merge Edge Cases in Component Based Design