Conflicts and outgoing changes

[WtfJoke]

For some unknown reasons the rtc workspace contains conflicts and outgoing changes (despite the fact the skript doesnt check in anything in rtc) after the changes of the next stream gets accepted.

This issue should try to find the cause and/or triy to avoid such behaviour.
I tried to fix this issue already by trying out different approaches, but until now I didnt found any solution.

However this might be an issue of rtc itself... Somehow it seem it cant handle that.

One approach which should be tested is that the workspace gets compared directly with the baseline of the components of the headstream. This would result in a longer migration (each stream would get pulled up to the highest stream instead of branching of while pulling up)

[WtfJoke]

I was able to analyze the issue a bit. I figured out why the conflicts and/or outgoing changes (which are not created by the migration, rather by accepting changesets) are there.

Any changeset/baseline which is not part of the current flow target gets displayed as outgoing changes and will most likely cause conflicts sooner or later.

I might have a solution, which might avoids the problem, but I need to test it first

[WtfJoke]

The solution mentioned in previous comment didnt worked out (Was testing it with a workspace without a flowtarget).Due a different approach on how to accept changes, this is not an issue anymore.
Now each stream gets migrated from the oldest state to the target-stream on its own.
Before I branched off on the fly and tried to migrate every stream more or less in one step.

[WtfJoke]

Is somehow still a problem. Needs to be more investigated. Might be another try worth to switch the old migration behaviour.

[WtfJoke]

As long as I set the flowtargets of the to be merged stream everything is fine (which I implemented in 0f4272b, 6010b2f).
So until not something new is poping up again, I will close this issue.

[WtfJoke]

From time to time we run into some conflicts in the rtc workspace. Allthough its rarely I hope its possible to find a solution
A possible explaination could be the strict accepting ordered by date.... If I check the history of some files, sometimes its possible that they are aranged not according the date.

[WtfJoke]

Implementation of more heuristic date sorting implemented in 1b87412 might solve this issue. (It keeps the order inside each component, but looks which component received a change earlier)

[WtfJoke]

The heuristic date sorting sadly doesnt solve the issue. Because the compare command returns the changes already ordered by date.

Here is a sample of a conflict happened during our migration (one of the easier one). The order displayed here doesnt match the date order (compare second and second last entry in picture). Until the changes doesnt go back into the same branch you get conflicts.

[WtfJoke]

The ordering of the changes produced by the compare command are not reliable (As already mentioned they get ordered strictly by date).

As I was searching for an alternative I found that the show history command works as expected (correct ordering) tested with the file mentioned above.

So I was quite enthusiastic for making this thing work. Sadly the history command is somehow limited to 100 results only (even with specificng maximum 100+).

So im stuck for the moment.

EDIT: Known defect in 4.0.6 --> https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=272979

https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=350617

[WtfJoke]

I found a workaround to get the history (user needs to provide it 👏 ) 😄
First tests looks very promising. The changes get in the order they were delivered. 🎉 Details will follow

[WtfJoke]

Details can be read here:
https://github.com/WtfJoke/rtc2git/wiki/Getting-your-History-Files

So this bug can be finally closed 😃