lock scenario - all files locked by default
Nicolas Dangeville (316●3●24●25)
| asked Sep 13 '13, 8:54 a.m.
JAZZ DEVELOPER edited Oct 10 '17, 11:13 a.m. by David Lafreniere (4.8k●7) We have a customer with the following use case:
showing 5 of 9
show 4 more comments
|
Accepted answer
Note: This forum topic does not yet have an official 'answer', however the answer was really flushed out in the comments to the original question (for those that may want to read through them).
Nicolas Dangeville selected this answer as the correct answer
|
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
A common scenario is for two different change requests to require modifications to the same file. How would you want that to be handled?
Hi Geoff !
I should have mentioned that this is a mainframe process. The CR tool makes sure that the program that is supposed to be modified is not included in another CR. The process of the CR tool can handle exceptions, in this case it is possible to switch the CR being worked on.
Our purpose is to integrate the RTC SCM with this external CR tool. This means setting up a process that controls ahead of time which files a developer is allowed to modify.
Another question. RTC locks currently only prevent delivery to a certain stream, so you can checkin as many changes as you want ... only the deliver is controlled by the locks. Will that be OK for this customer? The only exception is the web client, which does have modification-time locking support. Which client(s) will this customer want to use?
Hi Geoff,
Yes we expect the developers to deal with a single stream. This would be a pretty controlled environment with restricted stream visibility.
Your comment also applies to read-only components in a stream (when you have set the appropriate deliver pre-condition). It is possible to modify the file in the sandbox, even to check-in but deliver is prevented. I have heard the feedback that it comes too late in the developer's workflow.
To fix this, maybe there would be a way for the IDE to understand that the file is locked (or any other criteria) and warn the user that is should not be changed. Do you know if such an extension would be possible with an Eclipse-based editor ?
There is a work item requesting RTC-Eclipse support for preventing editing of a "locked" file: Prevent editing a file when it is locked by another user (77416) and there is a plan item for this work item: [CCM] Support for pessimistic locking / reserved checkout (171284) . So yes, such an extension is possible, but it realistically would need to be implemented by the product team. There is growing support for this plan item, but it isn't yet scheduled for a release, so I'd suggest adding your support via a comment on the plan item or some other means (VoiCE, RFE on developerworks, etc.).
You might also want to be aware of this enhancement request.
https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=72314
Thank you for the pointers. Yes my request relates to pessimistic locking.
Since it's not available yet, my option seems to be locking all files by default.
Do you see an issue having all the files locked by default ? Would performances be affected ? Any other side effect that I may have missed ?
The issue is, users can still modify files locally, even if they are locked. So, as Geoff says, they should be loaded not modifiable (read only) and only made writable after a successful locking operation.
I know of a few custom extensions that have been developed to support these kinds of scenarios. I am not aware of any of these being published and it is by no means a simple approach, as far as I can tell.
WRT locking all files, also note that there currently is a bug that results in Eclipse not showing all the files as being locked (but delivery to the locked files is still prevented). See work item If more than than 512 files are locked in a component, only about 512 locks are shown in the Eclipse package explorer (280745)