Trouble organizing perforce streams to accommodate multiple main branches with streams

Question

So we have a project where there are multiple "main" branches being worked on at once. So there is 1.0.0, 2.0.0, and 3.0.0. Things that go into 2.0.0 cannot go into 1.0.0, etc. Each branch gets merged forward, 1.0.0 > 2.0.0 > 3.0.0.

I don't think we can use the normal stream flow because if we setup release branches, you cant get feature branches off of them, plus these aren't "releases" just yet, they are still in active development. If we go below, then everything has to go through one main branch to get to releases and there's no way to segregate files.

So I guess my question is, is there a proper way to set up streams for something like this?

thanks

Answer 1

A lot of the assumptions around use of the mainline model come from an environment where releases are being cut relatively infrequently (twice a year), and only patched for critical bugs -- so changes that need to go from one release to another tend to be the exception rather than the rule. In this model, the vast majority of merges are simply from the newest release (e.g. while the release is being stabilized, which comes at a point in the cycle where there's very little activity in the release prior to that one) or from a dev branch back to the mainline, and from the mainline back to dev branches (since dev branches are mostly working on new features that are destined for the mainline but not any release branches). Changes only go from the mainline to a release branch if they're being manually cherry-picked to address a critical bug (which is rare), and never straight from a dev branch to a release branch. It's slightly awkward to cherry-pick a fix from an old release branch up to a bunch of later release branches, but it's very infrequent in this model so the awkwardness doesn't matter that much.

If you're very actively working on multiple releases simultaneously, the mainline model has less value since you need to either:

• merge between sibling/cousin branches (which mostly works okay but can get awkward if there's been a lot of refactoring)
• carefully cherry-pick changes to and from the mainline to enforce correct flow of change (which makes for cleaner merges but a bit more manual tracking)

The orthodox recommendation here would likely be to rethink your release methodology/policy to not require so much "waterfalling", but I'm assuming you have business reasons for requiring it to work this way. Given that constraint, I think you probably don't want to use the concept of different stream "types" and "flow" at all since those have assumptions about the mainline model built in, and what you're doing is fundamentally not a mainline development model.

To implement a non-mainline model in streams (which does still have some value without the flow-management guides since it'll help you manage your client views and whatnot) you'll probably want to use some combination of:

• make every stream after the initial mainline a development stream (that's the most permissive I think)
• set the mergeany option in every stream (that allows merging in all directions rather than trying to enforce "firmness" which is a mainline model concept)
• use the -F option when merging to ignore flow direction (I think mergeany makes this unnecessary if you use it consistently)