Does cross-stream deliveries understand the change timeline?
I encounter a weird scenario that I thought was going to be handled by RTC but apparently not. I would like to get some feedback on what we are doing wrong.
We currently have two streams for our plugin codebase: Dev and Integ. The Integ also functions as our fix stream and high-priority defects are implemented there so we can release a new update site to the client. Here is the timeline: - End of Sprint 1 was delivered from Dev to Integ without any problems. The two stream are now equal in terms of the codebase. Sprint 2 starts. Lets say that a file named FileConstants.java now exists on both streams at version C0. - Developer A made some changes(C1) to the file FileConstants.java under work item 100. The change is delivered to the Dev stream. - A high-priority defects was logged and assigned to Developer B. He worked under the Integ stream and delivered his changes (C2) which includes a modification on the FileConstants.java file. - After the delivery, Developer B reconciles his changes to the Dev stream by changing the flow target of his workspace to the Dev Stream and delivering his new change sets. A conflict was detected by RTC (with the changes made by Developer A) so Developer B performs a merge and delivers both his Integ changeset (C2) and the merged changeset (C3). - Along the sprint execution, Developer A and C makes some more changes on the FileConstants.java file on top of the changes made on the file. Lets call these C4 and C5. - At the end of the sprint, I created a new repository workspace (DWS) based on the latest contents of the Dev stream which constitutes the work done in this sprint. No errors were detected and all changesets were accepted. - I changed my DWS flow target to the Integ stream and all changes were detected as outgoing. - I tried delivering first the changes on Work Item 100 but then I got an error that the delivery operation cannot continue because it will constitute a conflict on the FileConstants.java file. I created a new repository workspace (IWS) based on the Integ stream and noticed that the file history differs based on where the repository workspace was created. If I look at the DW1 repository the history of FileConstants.java has this flow C0->C1->C2->C3->C4->C5 But from the IWS stream it looks like this: C0->C2 Accepting the change set from Work Item 100 will produce the history as C0->C2->C1 with a file conflict. Shouldn't RTC be able to recognize in the DWS->Integ delivery operation that it should treat C1 as a pre-requisite of C2 and thus insert it before C0 and C2? Right now I am doing manual merges on IWS but I think this will take some more time as I am going to get more conflict errors when it comes to C3 to C5. ciao! |
3 answers
|
An update to the scenario: I decided to use a different track and accept all Dev stream changes into my Integ-based workspace (IWS). Initially I was accepting the bottom changesets (Pending Changes view) which produced conflicts. I have the "Resolve Later" selected permanently so I am no longer asked if I want to do an auto-merge. While in the middle of it all I selected all incoming changesets thinking that it will produce all conflicts and then I can focus on resolving them one by one.
When I did a mass-accept operation the conflicts did show up and then disappeared. I switched IWS to the Integ stream but when I tried delivering the C1 changes it prompts the error that there is a conflict on the FileConstants.java file again. The recommendation is to accept all incoming changesets but I already switched the IWS back and forth on the Dev and Integ stream and no incoming change is becoming recognized and I don't know how to resolve the error. Merge has been completed. The approach I took was to 1. accept a small set of change set, 2. watch for conflicts, 3. resolve conflicts with proposed so they will get to be recorded in changeset 4. Repeat from step 1 until all change sets are accepted. 5. Compare the files in the merge changeset with the latest files in the Dev stream. There shouldn't be any changes or else take the versions in the Dev stream and check them in. 172 changesets only took 2 hours to process using this approach. :| ciao! |
Hello,
The simple answer to your question is : no, the ordering is not preserved when delivering/accepting change sets between workspaces. 2 workspaces may contain the same change sets in completely different order. However, if you were to create a baseline and flow it to the stream, then the ordering of the stream and your workspace would be identical. When other users accept this baseline, this would also give them a identical prefix of history, ordered as per the changes in the baseline. We encourage this usage for other reasons as well (it improves performance of comparing workspaces/streams, and allows for more re-use of scm data structures behind the scenes). Hope this helps, JohnC SCM Server ramfree17 wrote: I encounter a weird scenario that I thought was going to be handled by |
Geoffrey Clemm (30.1k●3●30●35)
| answered Feb 17 '09, 3:18 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
I've submitted workitem 71364, asking for "preserving the change-history
of a file across deliver and accept", to avoid this kind of anomaly. (I figure it never hurts to ask :-). Cheers, Geoff John Camelon wrote: Hello, |
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.