Five Real-World Strategies for Perforce Streams

Editor's Notes

• #3: 10 years contractor on and off for TomTom, some other jobs in between
• #5: To give some indication of the size of Perforce in TomTom Streamed depot ~2.5 years in existence (since May 2012)
• #7: Parent/child stream relationship: explain the ‘levels of stability: from dev -> dev -> main -> release’ “resolve on child paradigm”: or “Copy-up is trivial” This is the true power of perforce streams! Put focus here. Stream specification vs branch mapping: p4 commands support the “–S <stream>” option, which maps the stream view, while the same commands also allow for direct branch mapping /… notation (p4 integrate, copy, merge, …) Moving workspace: Very useful, but not all users like it. We have seen on numerous occasions submits in the wrong stream because the user forget the workspace was moved before. Use or don’t use per user-preference. Naming convention: we have: One mainline only, called ‘main’ All release stream names start with ‘rel-’ All development stream names start with ‘dev-’ All streams are named ‘<parentname>-<extension>’ to show clearly the parent/child structure, which is very convenient most of the time. It gives issues when reparenting (and would call for renaming, but that confuses again because of the streamname/branchname differences) Exception is of course all dev streams below main (they don’t start with ‘main-’) Exception is development stream below release stream (starts with ‘dev-’ and not ‘rel-’) Renaming a stream will be confusing for users and is not advised, based on experience. Deleting streams as to keep the streams overview clean. Note that it does not remove them from the left-hand side of p4v (@perforce; can this become a nested list?) TODO: add “use p4 <command> –S <stream>” option for all p4 commands that support it (see also later ‘streams vs branch mapping’)
• #8: Cherry-picking concept is following the parent/child relationship, but does not do the full sets of changelists. Instead it does one or selected few sets of changelists.
• #9: Cherrypicking happens, for example, when a specific change (say bugfix) needs to be propagated, but a full copy-up (or merge-down) is not wishful yet (because the full work on some task has not been completed). As we have streams for each stream below the mainline we have this behavior often. We have such setup because the teams like ‘working in their own area and setup’. Therefore teams cherrypick from their real development stream into a prep(eration) stream and from there copy-up into the mainline. TODO explain other situations where this might occur Call out to Perforce for official support and a whitepaper on this behavior: “Hey Perforce representatives; maybe you can support this officially with a ‘p4 –S <stream>’ command and describe the desired workflow in a nice whitepaper ?”
• #11: Because there is no flow enabled from main into the release stream (by design, but can be enabled) it is not possible to normally integrate a fix from the mainline environment into the release. You could enable the flow in the stream specification of the release stream, but you’d have to copy a full set of changes, which is still not what you’d want. Making the edits twice manually, one in development stream and one in the release stream, is not a wishful situation as it is/can be lot of duplicate work and it opens the door for typos and (minor) differences. Call out to Perforce representatives again for another official support and whitepaper.
• #12: Typically the same situation as before; consider a situation where 1 team/workpackage is depending on another that is not ready to deliver fully into the parent/mainline it happens that there is a crossintegration done to get the preliminary work quickly from one development stream into the other. Another option here is to be creative with import statements in the stream specification of dev-Y, but that can be cumbersome to maintain and gives issues if dev-Y wants to edit the imported files. Note: writable imports will be available in p4d 2014.2
• #14: Tell the story of our user who did this and wasn’t even aware he did wrong. “but I used p4 copy” was his actual first response when asked about how he managed to copy versions.txt into main. Another option here is to be creative with import statements in the stream specification of dev-Y, but that can be cumbersome to maintain and gives issues if dev-Y wants to edit the imported files. Side effect is every stream gets the update via import whenever it changes on main, this is undesirable Note: writable imports will be available in 2014.2 P4D Educate your users: Use “p4 <command> –S <stream>”
• #16: Task streams can be converted into development stream, but cannot convert back
• #18: You can also do this with real (release) streams, but using virtual streams makes it very clear there isn’t any special branch, there isn’t any data stored specifically for these canaries and cleanup is easier, just delete the stream specification, no trace is left behind.
• #20: ‘p4 integrate –f’ resets your integration history and causes unexpected results further down the line. We used it as our ‘go to hammer to hit any nail’ and since have moved away, preferring ‘p4 copy’ commands instead. TODO: can we make the road go behind the template footer ?
• #21: Educate your user base: It seems so obvious, but instilling the true reasons and power of streams in combination with the appropriate commands with prevent you from some common mistakes Cherry picking integrations: Sometimes it is needed. Think about it, be prepared for the questions. Done with regular integrations that is not ‘streamy’ but works good. Cross integrations: Similar to cherry picking integrations, where it also ignores the common direction of merge and copy flows. @Perforce; can you support this use cases better ? Stream specification versus branch mapping: Use streamy commands wherever and whenever possible. When you use branch mapping; make sure you thought about its consequences. Task and virtual streams: Task streams have limited use, hard to define when you should choose for task rather than regular development type. @Perforce; maybe you can comment on this ? Virtual streams can be useful indeed, especially to limit the size of your workspaces, but some other creative use exists.
• #22: Please pay attention to the mismatch in my email address, but really, my name is spelled correctly (that’s how my mum writes it, and she’s always right, as usual for mums) and my email is also correct.