How to know about conflicts on different streams ?
RTC doesn't use Check-outs because it is parallel development.
|
One answer
|
I saw that Support pessimistic locking of versionables is planned for 26 Apr .
Regards,
Yehiel
Comments Even if that would be implemented, I am not convinced it would work across several streams. I would assume that it would work similar to locking today, be more automatic, but only apply to one stream.
Geoffrey Clemm
commented Mar 18 '13, 7:51 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Note that the "due date" set on this work item does not mean that it is in plan for 26 Apr ... it just means that by 26 Apr it will be decided whether or not it will be added to the plan. The fact that it is Planned-For Backlog means it has not yet been committed to any particular release.
Geoffrey Clemm
commented Mar 18 '13, 8:02 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
WRT Ralph's comment, I believe the request is to make it work across all the streams in the repository (unlike RTC locks, which only apply to a single stream). It is true that checkouts in other repositories would not be detected, but I think that would be acceptable.
Thanks for the clarification Geoff! |
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.
Comments
The paradigm RTC follows is that of an optimistic locking. If it is necessary that a developer wants to exclusively edit a file, than there is the possibility of locking it. This information is than available for everyone. Every developer that wants to edit the file that is locked will be informed about that lock. So with that the amount of merge conflicts will be reduced.
On the other hand: If two developers are working very close together, they can directly see their conflicts if the set their flow targets to the other developers workspace. With that they can immediately resolve the conflicts.
Hi Henning,
The problem comes when two different teams (on different streams) touch the same global file: each team don't know about the otehr. The result is that each team delivers it's feature after the development completed, and on that point - the merge is complicated.
If developer will get notification when he check-in file that his friend already checked-in - than we will know about conflicts before the merge is too complicated. That is the value of the old checkout.
About the locks, we need option to lock all the streams in the system (today we need to check every single stream) and to lock also future streams.
Thanks.
I am not sure that ClearCase would prevent checkout if a file is checked out in another branch - which is similar to another stream in RTC.
WRT ClearCase, it is true that a "reserved checkout" is for a single branch/stream, but you can write your own checkout trigger that checks for checkouts in any branch/stream (at least, all branches/streams visible in your replica).