Reparenting is the process of moving a stream to a different place within the stream hierarchy. Reparenting is often a natural occurrence in the evolution of a codeline. You might reparent a stream to accommodate a new workflow or to fix an error in the original design of your stream hierarchy.
You might also reparent a stream to leverage the built in integration capabilities between parent and child streams. Remember that within streams, to preserve a hierarchy of increasing stability, you propagate all changes, by default, between parent and child streams. If you need to integrate changes between two unrelated streams, for example, changes from another development stream into your development stream, you can reparent your stream and then use streams integration logic to integrate your changes.
To reparent a stream, you simply drag and drop the stream to a new parent in the Stream Graph. Alternatively, you can edit the parent stream field in the stream settings through the GUI dialog or directly in the stream spec from the command line.
We'll present a few examples to illustrate some practical reasons for reparenting streams.
In this example, you've created a private development stream as a child of the current 1.1 development stream to do some R&D on a new product feature. The preliminary development has gone well and the project lead has asked you to move the files from your private development stream to the 1.2 development stream. To propagate your files to the 1.2 development stream, you decide to reparent your private stream to the 1.2 development stream so you can use the built-in integration behavior of streams to move your code. To reparent the stream, you simply drag and drop your private development stream from its current position to its new position as a child of the 1.2 development stream. You then integrate your changes into the 1.2 development stream by following the hints and workflow illustrated in the Stream Graph.
The default flow of change between a release stream and its parent is unidirectional, from the child to the parent. You typically propagate changes made in release streams down to the mainline stream. In the case where you add a subsequent release stream to an existing project, the flow of change between the original release stream and the mainline stream needs to now go through the new release stream to the mainline stream to maintain the integrity of the code across all of the codelines.
To obtain this functionality, you reparent the existing release stream as a child of the new release stream. The flow of change for bug fixes in the set of release branches now goes from the earliest release stream, down to the more recent release stream, and then, finally, down to the mainline.
In our final example, assume that you have a series of parallel development efforts taking place in your organization. In the original design of your stream hierarchy, each independent development stream was configured as a child of the mainline stream. Since implementing this depot, you have determined that you need another stabilization layer between the development streams and the mainline so all of the development work across the three groups can be combined and tested before being pushed to main. To implement this change, you first determine the flow of change required between the new stream, the mainline, and each of the existing development streams.
You determine that the flow of change across the streams should be bi-directional and implement the merge down/copy up integration behavior. You decide to use the development stream type for your new stabilization stream and tailor the stream view for the new stream to have all of the files required by the development streams as a whole. After creating the new stream as a child of main, you reparent the existing development streams as children of the new integration stream.