What is the best practice to choose WIs and create baseline?

In RTC 4.0.5 we delivered additional support when trying to accept change sets which have a gap (often encountered when trying to backport fixes). In a very brief summary of the feature, when you accept change sets with a gap, you can now follow a gap workflow that accepts one change set at a time and, for change sets that contain gaps, creates a new change set (with aided traceability), that contains the equivalent changes. This means users will not have to accept the change sets 'as a patch'. Applying change sets as a patch has limitations compared to the new workflow (as discussed in the article below).
This feature is summarized in the RTC 4.0.5 'New & Noteworthy' page:  https://jazz.net/downloads/rational-team-concert/releases/4.0.5?p=news#scm-improve-usability-405-m1
Below are some videos which show this feature:
-Accepting multiple change sets with gaps in the RTC 4.0.5 client for Eclipse IDE: https://www.youtube.com/watch?v=28raag5RdzU
-Accepting a change set with a gap in the RTC 4.0.5 client for Eclipse IDE: https://www.youtube.com/watch?v=TucVu_BgB7E

In RTC 5.0 we added a "fill the gap" feature where the change sets that fill the gap are shown to the user, allowing them to either accept all the change sets or to continue with the gap workflow that was available in RTC 4.0.5.
This feature is summarized in the RTC 5.0 'New & Noteworthy' page: https://jazz.net/downloads/rational-team-concert/releases/5.0?p=news#eclipse-fill-gaps

The classes that are involved for filling the gap include (available in RTC 5.0):
client side: IWorkspaceConnection.findChangeSetsToAcceptToFillGap(...)
server side: IScmQueryService.findChangeSetsToAcceptToFillGap(...)

Both features are explained in detail in the "Improved Gap Handling for SCM" article: https://jazz.net/library/article/1372

I would also recommend reading the other answers provided in this question as there appears to be some back-and-forth discussion.

Thanks for the screenshot, it helps a lot in understanding your use-case.

You did everything right, but think now about why you are doing it. This is a typical flow for fixing a bug in an older release, "baseline-feature1" can be considered a stable point that you gave a customer. Now, since then all your development has moved on, when you backport "feature3" to the "baseline-feature1" release you can't take the change set as is because it's built upon a different history, it depends on feature 2. This is because you have the same files modified in feature2 and 3.

Thus, you have to create a new change set you can assign it to the same work item if you like, to backport it without the other changes in depends on.
When this is done, you can either deliver to a new stream "iFixes". You don't typically deliver this to the existing stream, because this would imply that you want to discard feature2, which didn't seem to be the purpose of your use case.

Now if you want to instead discard feature2, we recommend you "reverse" the change, which creates an inverse change set, and deliver that.

Jean-Michel

Okay, but I have more questions about it =)

You did everything right, but think now about why you are doing it. This is a typical flow for fixing a bug in an older release

Could be. But in my case are improvements in the software (no bugs) and feature2 is not 100% ready in time for the package. So we want to create a package without the feature 2.

You probably have this control in jazz.net too.
If a feature is planned for 2.0M3 and it was not ready in time?

So I dont want to discard the feature2.

-----------

Check if this is correct:

http://www.brunobraga.com.br/img/jazz/rtc_print4.png

After that, the next package with feature2 - "baseline feature 1,2,3", I need to do:
1) change the flow target of my workspace for "Stream iFixes"
2) get a "baseline feature 1 and 3"
3) change the flow target of my workspace for "Main Stream"
4) accept the feature 2
5) make the necessary merge
6) back my flow target for "Stream iFixes"
7) do the checkin/delivery and create a baseline

That is correct?

Using this approach the "Stream iFixes" exist only to store baselines, you agree?

> Using this approach the "Stream iFixes" exist only to store baselines, you agree?

Correct. That stream contains the configuration with a cherry picked set of change sets. It's good to keep it around for the next feature you have to include. Alternatively, you could create a baseline, give it a name, and delete the stream. At some point in the future, when you have to add new iFixes, just create a new stream from the baseline and repeat the process over again.

Jean-Michel

ok, thanks Jean.

Perhaps if the baseline has an attribute "recommended" (y / n) we can checkin/delivery to iFixes, create a baseline and move it to main immediately, using this baseline as "not recommended".

possible baseline states
recommended (default) - display in history and developers incomings
not recommended - display in history (only) using the "show baselines"

It can prevent someone accept the new baseline (incoming) and lose some features (like feature2).

I believe the reason Bruno wants to be able to deliver this backport to
the development stream is that their policy is to periodically deliver
everything in the patch stream to the development stream, to ensure that
all of the bug-fixes made in the patch streams are merged forward into
development).

This is reasonable/desirable, because if you have a fix that you know
you want to make in older streams, you commonly will make it first in
the oldest (patch) stream you are maintaining, and then "forward merge"
it to the later streams (because forward merges are commonly simpler
than backports). So the simplest thing is to just periodically merge
everything in the patch stream into the next later patch stream (which
will eventually cascade all fixes into the development stream).

But there are cases where you don't realize that a change you are making
in the development stream needs to be applied to earlier streams
("backported") until you are done making the change in the development
stream (requiring a selective backport).

So what you'd like the system to do is to know that the backport change
set is logically "included" by the existing change set, so the merge of
a backpatch into the change-set it was created from is ignored during
the auto-merge.

I once wrote up an algorithm to do this ... it turns out to be a lot
harder than it might look (:-). And Jazz SCM does not do this (yet :-).

Cheers,
Geoff

jlemieux wrote:

Thanks for the screenshot, it helps a lot in understanding your
use-case.

You did everything right, but think now about why you are doing it.
This is a typical flow for fixing a bug in an older release,
"baseline-feature1" can be considered a stable point that
you gave a customer. Now, since then all your development has moved
on, when you backport "feature3" to the
"baseline-feature1" release you can't take the change set
as is because it's built upon a different history, it depends on
feature 2. This is because you have the same files modified in
feature2 and 3.

Thus, you have to create a new change set you can assign it to the
same work item if you like, to backport it without the other changes
in depends on.
When this is done, you can either deliver to a new stream
"iFixes". You don't typically deliver this to the existing
stream, because this would imply that you want to discard feature2,
which didn't seem to be the purpose of your use case.

Now if you want to instead discard feature2, we recommend you
"reverse" the change, which creates an inverse change set,
and deliver that.

Jean-Michel

> Using this approach the "Stream iFixes" exist only to store baselines, you agree?

Correct. That stream contains the configuration with a cherry picked set of change sets. It's good to keep it around for the next feature you have to include. Alternatively, you could create a baseline, give it a name, and delete the stream. At some point in the future, when you have to add new iFixes, just create a new stream from the baseline and repeat the process over again.

Jean-Michel

By the way, to create a baseline in a stream, is it mandatory to create it first in a repository workspace and deliver it to the stream, or it is possible to create a baseline directly in the stream?

Thanks in advance.

You can create directly in stream.

Bruno:

how can I create a baseline directly in the stream? I have not found a way to do it .

When you right-click on the stream, the context menu enable you to create a snapshot but not a baseline. When creating the snapshot you can select only one component , but not creating a baseline. Im using the RTC Eclipse client.

Thanks in advance.

You can create directly in stream.

In RTC the baseline was design to save state of components, and snapshot of streams.

One baseline save state of one component and one snapshot save state of N components.

"When you create a snapshot, you implicitly create a baseline for any component in your workspace that does not already have one." (RTC Doc)