Does the inclusion of a changeset into a stream matter where it came from?
We have several active release code streams and a new development code stream.
If a changeset can exist in multiple code streams, is there any dependence on how it got there?
It seems that only that the previous changsets would allow a changeset to exist in multiple places? And that doesn't happen if changesets go out of order.
In other words, for putting a change into v2, it makes no difference if the changeset is found from the v1 stream, the work item, or the trunk (new development). Suppose that v1 and v2 were both branched off of trunk. Any change that goes in v1 should go into v2 and that should go into trunk. The reverse is not true. We do our fixes in the oldest release that the issue is reported. So we fix in v1 and then need to forward port. Does it matter what order the changeset is forward ported to the different branches?
This was NOT the case with Perforce, as you had to pick a steam, as a change could NOT exist in multiple streams, UNLIKE RTC. Perforce was very finicky about
I suppose there could be some voodoo behind what RTC is doing, but I was told by an RTC SE that changesets behave more like patch files, as I have described.
And if that is the case, why does it matter what direction changesets are brough into different streams? What seems to matter is that the changes behind a single file go in order.
Can anybody confirm this? Any comments?
One answer
A single change set can exist in multiple streams. It doesn't matter how the change set gets into the stream.
The one requirement you need to watch out for is this: For a change set to get into a stream or a repository workspace, that stream or workspace must contain all the dependent change sets. In other words, you aren't allowed to create any version gaps. A dependent change set is a change set that contains an earlier change to one of the files in your change set.
Fixing the bug in the oldest stream first and then copying the change sets to the newer streams is the right way to do it. If you do that consistently, you are unlikely to run into version gaps. You will likely have to perform merges when you copy the change sets to the newer streams (since the newer streams may already have changes to the files that weren't in the older streams).
If you were to do it the other way around, fixing the bug in the main development stream and then trying to push it to the older release streams, you would likely run into version gaps. When that happens, you wouldn't be able to use the same change set in all the streams, but you would have to recreate the fix in a new change set in the older stream.
Comments
Note that RTC will help you recreate the fix in a new change set in the older stream by requesting that RTC create a "patch" for the fix, which you can then apply to the older stream. Also, a high priority enhancement for the next version of RTC is to allow you to do this kind of operation without having to create a patch.