What is the best practice to choose WIs and create baseline?
Bruno Braga (480●1●36●21)
| asked May 12 '09, 5:06 p.m.
retagged Jun 24 '14, 11:11 a.m. by David Lafreniere (4.8k●7)
Hi guys,
Our baselines (snapshots) were created directly in the stream (with the latest version of all files). Now I'd like to choose some of the incoming activities and create a package (release) only with them. But I have some questions. Implementation of tasks feature 1, feature 2 and feature 3. These three tasks modify the same file web.xml, ok? The last snapshot baseline-feature1 has the feature 1 only. So, I need to get baseline-feature1 and add the task feature 3 only, ok? The task "feature 2" began to be developed first, but I dont want to add it to the package at this time. After I load baseline-feature1 I see that: The feature 3 was implemented after feature 2 and accept it alone will create a "Pending Patch". Its ok. But the merge "Pending Patches" into workspace will create a new version of web.xml (with feature 1 and feature 3). I think I need to do checkin of this new web.xml to add it into a new baseline. But if I do that, this version will be the last version of the repository and it will be propagated to the team. If the developers accept this incoming, the changes in web.xml for "feature 2" will be deleted. |
Accepted answer
David Lafreniere (4.8k●7)
| answered Jun 24 '14, 11:07 a.m.
FORUM MODERATOR / JAZZ DEVELOPER edited Jun 24 '14, 11:09 a.m.
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. Bruno Braga selected this answer as the correct answer
|
10 other answers
|
|
|
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) |
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. |
|
|
> Using this approach the "Stream iFixes" exist only to store baselines, you agree? 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. |
Geoffrey Clemm (30.1k●3●30●35)
| answered May 14 '09, 6:51 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
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 |
|
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). |
> 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 |
|
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: 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? |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.