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