It's all about the answers!

Ask a question

backporting changes from Main stream to Maintenance stream


Riccardo Rossi (3187) | asked Nov 22 '10, 11:21 a.m.
retagged Jun 24 '14, 11:13 a.m. by David Lafreniere (4.7k7)
I had read the article http://jazz.net/library/article/40, in particular we are interested in the section 2.4 (backporting changes from Main stream to Maintenance stream), but still have some doubts:

1) The article describes the method of Change Flow Target to the Maintenance stream, and then runs Replace With > Latest from Maintenance. Then you have to switch back on the Main stream , accepts the single change set you want to backport and then switch back on the Maintenance stream to deliver this changes; at the end of the switch back on the Main stream and reload the latest.
Here my issues:
a) if the two streams are too different all this reload operations will take too much time (some minutes?)
b) If i had some changes pending in my outgoing view they are destroyed by the above operation and cannot be resumed. Probably i can put them in Suspended mode before the switch, but this could be prone to unrecoverable errors by not expert developers (Also some changes not checked-in (unresolved) will be destroyed)

2) The article describes that if Main stream and Maintenance stream have diverged significantly, probably change set cannot be accepted easily; it is offered an alternative to apply the change as a patch to the workspace"
Here my issues:
a) if the fix to backport contains binary files the patch cannot be used. How can i resolve that?

3) When i accept a delivered change set in another stream and there is no gap in the file history the change is backported correctly but the change set is still one, so there is no trace of the person that delivered the first fix and the person that deliver the backporting on the other stream (we lost the owner of the backporting). Also looking at the Work Item associated with both the deliveries we can see only 1 change set (we lost the info that a back porting was done)

4) In our code we have only one Project as code base dir and we change the name between streams. So the Project base dir name for the Main stream is "Main" and the Project base dir name for the Maintenance stream is "Maintenance" . This give us the ability to load 2 streams in the workspace at the same time. But we saw some visualization defects in the RTC client that created some confusion (For example the Project base dir name of the files delivered in one change set is visualized in a different way depending from the workspace loaded at the moment. Or for example we are not able to apply a patch to the right Project if both are loaded).
Do you think we will have more serious problems in the future if we continue to use different Project base dir name for different streams? Do you think we have to use the same Project base dir name for both the Main and Maintenance streams to avoid problems?

5) To avoid some of the above problems (1 and 3 and 4) we found an alternative way to perform the backporting.
I'd like to know if it is a good way or we are doing some errors (we tried it and seems to work). Here the procedure we applied:
Environment preparation:
- In your current Eclipse Workspace load ONLY your current development stream (Main Stream in this example). (In this example we call this workspaceMain)
- If you already loaded the other stream (Maintenance Stream in this example) you have to clean up this: unload it and delete the filesystem directory (Maintenance).
- Create a new Eclipse Workspace load ONLY your secondary development stream (Maintenance Stream in this example). (In this example we call this workspaceMaintenance). Click File->Switch Workspace->Other then create a new workspace for the other stream you are interested into.Set both "Copy Setting" fags in the "select workspace" windows: this will apply the same visual behavior in the new eclipse workspace.
- In the new Eclipse Workspace workspaceMaintenance repeat the initial procedure to connect to Jazz: You only need "New repository connection" and "Connect to a project area"
- In the new Eclipse Workspace workspaceMaintenance load ONLY your secondary development stream (Maintenance Stream in this example)
You have now created the two Eclipse Workspaces and are able to port your fix:
- Go back in the Eclispe Workspace (workspaceMain) where is your current development stream (Main Stream in this example). Click File->Switch Workspace->c:\workspaceMain
- On the defect page select the change set you have delivered on Main stream and that you want to port on the Maintenance. Automatically the "Change Explorer" view will open showing you the fixed done on Main. Right click on the base dirs "Main" New->Patch and select save location=clipboard (it's the default): this will create a Patch (it's simply a group of files in RTC) in the memory.
- Go to the Eclispe Workspace (workspaceMaintenance) where is your secondary development stream (MaintenanceStream in this example). Click File->Switch Workspace->c:\workspaceMaintenance
- In the Navigator view select the Maintenance project and right-click Team->Apply Patch follow the next steps. The tools created a Patch in your Pending View.
- In your Pending View select the above created Patch and click "Merge into workspace". A new empty change set is created (or fixes are applied to the current change set if any). A merge could be requested by the tool if needed.
- Associate the change set to the defect you are porting and deliver

6 answers



permanent link
David Olsen (5237) | answered Nov 22 '10, 8:23 p.m.
JAZZ DEVELOPER
On 2010/11/22 8:23, rrossi wrote:
b) If i had some changes pending in my outgoing view they are
destroyed by the above operation and cannot be resumed.

Don't use your regular workspace for this. Have a repository workspace
dedicated to moving changes from the main stream to the maintenance
stream. That way you will never have to worry about stomping on your
own changes.

a) if the fix to backport contains binary files the patch cannot be
used. How can i resolve that?

Migrate the change for the binary files manually. If the version in the
main stream is the one you want in the maintenance stream, just copy the
file. If the maintenance stream needs to be different from the main
stream, then you have to figure out how to get the correct changes into
the file, and that varies depending on the kind of file. Is this an
issue that crops up all the time, or just once in a while?

3) When i accept a delivered change set in another stream and there is
no gap in the file history the change is backported correctly but the
change set is still one, so there is no trace of the person that
delivered the first fix and the person that deliver the backporting
on the other stream (we lost the owner of the backporting). Also
looking at the Work Item associated with both the deliveries we can
see only 1 change set (we lost the info that a back porting was
done)

That's working as designed. And I think it's a good design. I like
that a change set can be delivered to multiple streams without any
merges or new versions of files.

RTC could make it easier to identify all the streams that contain a
particular change set, which would help you identify what has or has not
been backported. But I see that as a minor issue that would not be
fixed by forcing people to create a new change set just to deliver
something to an additional stream.

If you are driving your builds form RTC, then the "Included in build"
links in the work item will help you know what streams that work item's
change sets are in.

Do you think we will have more serious problems in the future if we
continue to use different Project base dir name for different
streams? Do you think we have to use the same Project base dir name
for both the Main and Maintenance streams to avoid problems?

I can't give an authoritative answer. But I think you will run into
problems and that you shouldn't have different directory names based on
the release. You should have different versions of the same file for
each release, not different files. I don't think the ability to load
two different streams in the same sandbox or Eclipse workspace is worth
the hassle.


5) To avoid some of the above problems (1 and 3 and 4) we found an
alternative way to perform the backporting.
I'd like to know if it is a good way or we are doing some errors (we
tried it and seems to work).

That should work. But you are using patches for everything, which I
don't like. It may just be a difference of opinion.

In general, it is better to make the change in the maintenance stream
first and then port it to the main stream. You are more likely to be
able to move the original change set (maybe with an additional merge
change set) and not have to resort to a patch.

Of course you can't always do that. Sometimes you make the change in
main before deciding that it should also go in maintenance. But I think
changing maintenance first should be the normal mode of operation.

--
David Olsen
IBM Rational

permanent link
Riccardo Rossi (3187) | answered Nov 23 '10, 7:05 a.m.
Thank you very much for your prompt answer.


Don't use your regular workspace for this. Have a repository workspace
dedicated to moving changes from the main stream to the maintenance
stream. That way you will never have to worry about stomping on your
own changes.

The tool try to overwrite my regular workspace on the file system. How can i load another repository workspace with the same project base dir name?



RTC could make it easier to identify all the streams that contain a
particular change set, which would help you identify what has or has not
been backported.

I can locate a change set in a Stream but i did't find how to identify all the streams that contain a particular change set? (I don't use the RTC build engine)

Thanks,
Riccardo

permanent link
Ralph Schoon (60.7k33643) | answered Nov 23 '10, 9:53 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Thank you very much for your prompt answer.


Don't use your regular workspace for this. Have a repository workspace
dedicated to moving changes from the main stream to the maintenance
stream. That way you will never have to worry about stomping on your
own changes.

The tool try to overwrite my regular workspace on the file system. How can i load another repository workspace with the same project base dir name?


you unload the one repository workspace and load the other one.



RTC could make it easier to identify all the streams that contain a
particular change set, which would help you identify what has or has not
been backported.

I can locate a change set in a Stream but i did't find how to identify all the streams that contain a particular change set? (I don't use the RTC build engine)

Thanks,
Riccardo

permanent link
David Olsen (5237) | answered Nov 23 '10, 11:23 a.m.
JAZZ DEVELOPER
On 2010/11/23 4:08, rrossi wrote:
The tool try to overwrite my regular workspace on the file system. How
can i load another repository workspace with the same project base dir
name?

If you are using the Eclipse client, then have a separate Eclipse
workspace. Switch to the other Eclipse workspace (or start up a second
copy of Eclipse) when you need to switch from regular development to
migrating change sets.

At least that's what I've done when faced with this situation, and it
has worked well enough for me. It may or may not be the best solution
for you.

I can locate a change set in a Stream but i did't find how to identify
all the streams that contain a particular change set? (I don't use the
RTC build engine)

I have never tried to find all the streams that contain a change set
(since I use RTC to run builds and can use the "Included in build" links
to find out what I need to know), so I don't really know what I am
talking about. But I believe that there is not a good way to do it in
RTC 2.0. I don't know if that has changed in RTC 3.0.

--
David Olsen
IBM Rational

permanent link
Geoffrey Clemm (30.0k23035) | answered Nov 24 '10, 12:38 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
David is correct ... you currently cannot ask for all the streams that
contain a given change set. This functionality is requested in work
item 100643. Please feel free to add a comment to indicate your
interest/support.

Cheers,
Geoff

On 11/23/2010 11:14 AM, David Olsen wrote:
On 2010/11/23 4:08, rrossi wrote:
I can locate a change set in a Stream but i did't find how to identify
all the streams that contain a particular change set? (I don't use the
RTC build engine)

I have never tried to find all the streams that contain a change set
(since I use RTC to run builds and can use the "Included in build" links
to find out what I need to know), so I don't really know what I am
talking about. But I believe that there is not a good way to do it in
RTC 2.0. I don't know if that has changed in RTC 3.0.

permanent link
David Lafreniere (4.7k7) | answered Jun 24 '14, 11:35 a.m.
FORUM MODERATOR / JAZZ DEVELOPER
Note: Please read the other posted answers to this question as they appear to be a back-and-forth discussion. Since part of this question involves backporting and the possibility of gaps, the following information should also be useful:

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

Your answer


Register or to post your answer.