lock scenario - all files locked by default

Nicolas Dangeville

JAZZ DEVELOPER (316●3●25●25) edited

Oct 10 '17, 11:13 a.m.

We have a customer with the following use case:
They have an external tool that manages change requests. Each change request lists the files that need to be modified. The change request is assigned to a developer. The developer should be able to modify the files listed in the change request, but only these files and none other.

We thought of the following implementation for this use case:
By default, all the files of the stream are locked, and the lock belong to a specific user (for example, the team leader). When the change request is assigned to a developer, a scm command line script is triggered to change the ownership of the lock to the developer for the appropriate files. When the developer finishes his work and close the change request, the opposite action is triggered (the lock is owned again by the team leader).
Our question is:
- does this make sense ? or is there a better way to do this
- is it reasonable to have all files of a stream locked by default or are there performance implications doing this.

Many thanks

0 votes

Comments

Geoffrey Clemm

FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Sep 13 '13, 11:07 p.m.

A common scenario is for two different change requests to require modifications to the same file. How would you want that to be handled?

Nicolas Dangeville

JAZZ DEVELOPER Sep 16 '13, 3:49 p.m.

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.

Geoffrey Clemm

FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Sep 16 '13, 3:53 p.m.

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?

Nicolas Dangeville

JAZZ DEVELOPER Sep 16 '13, 4:08 p.m.

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 ?

Geoffrey Clemm

FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Sep 16 '13, 5:07 p.m.

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.).

Karl Weinert

JAZZ DEVELOPER Sep 16 '13, 7:43 p.m.

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

Nicolas Dangeville

JAZZ DEVELOPER Sep 17 '13, 3:12 a.m.

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 ?

Ralph Schoon

FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Sep 17 '13, 3:35 a.m.

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.

Geoffrey Clemm

FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Sep 17 '13, 10:49 p.m.

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)

showing 5 of 9 show 4 more comments

1 answer

7,486 views

0 votes

Accepted answer

Permanent link

David Lafreniere

FORUM MODERATOR / JAZZ DEVELOPER (4.8k●7) Oct 10 '17, 11:12 a.m.

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).
The quick answer to this question though was the need to have a "Pessimistic Locking" feature, which was delivered in RTC 5.0.2 in the following Plan Item:
[CCM] Support for pessimistic locking / reserved checkout (171284)

Nicolas Dangeville selected this answer as the correct answer

0 votes

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.

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers

Answers and Comments

Question details

rational-team-concert

× 43,075

usage

× 12,144

source-control

× 890

lock

× 67

file

× 56

pessimistic

× 10

Question asked: Sep 13 '13, 8:54 a.m.

Question was seen: 7,486 times

Last updated: Oct 10 '17, 11:13 a.m.

lock scenario - all files locked by default

Comments

1 answer

7,486 views

0 votes

Accepted answer

Your answer

Follow this question

Question details

Related questions