Note that because a stream inherits the view of the parent stream, reparenting a stream that does not, to some extent, share a common set of files with the new parent, can have a drastic impact on the reparented stream's view. In short, the overlap between the parent and child views determines which files are included in the reparented stream.

For example, suppose I have a development stream that has three primary branches…

The path settings for the dev branches is…

If I choose to reparent the dev_db stream to dev_gui, no files are populated to the new dev_db stream because its new parent, dev_gui, does not share the files contained in dev_db.

So before reparenting, you should examine the views of the affected streams and make sure you'll achieve the results you're looking for by reparenting.

Habitual and frequent reparenting can also place additional demands on the server as the server needs to recalculate the integration state between streams each time you reparent a stream.If you find yourself reparenting streams on a regular basis to accommodate your workflow, it might signify that there are problems with the design of your stream hierarchy.

Are there other options to reparenting?

In the case where you need to integrate changes across streams that are not related and you don't feel that reparenting is appropriate, you can always manually specify the source and target for an integration directly within the integrate dialog, bypassing the default streams integration behavior. Although this circumvents the built-in controls within streams for regulating the flow of change, it might sometimes be necessary.

Note, however, if you find yourself regularly going outside of the normal streams integration processes to propagate your changes across codelines, you should revisit the design of your streams hierarchy or the appropriateness of using streams for the task at hand.

Course - Using Streams to Simplify Codeline Management