Locking resources - Are locks personal?
I have tried out locking a file as follows, working with two workspaces belonging to me:
In one workspace in a stream, I locked a file. The doc says "A resource that you have locked will appear as an incoming pending change to other users." But in the 2nd workspace in the stream no incoming pending change is shown. The file is shown as locked by me. The doc says "Only you can modify a file that you have locked." Strictly speaking this is true: I can modify the file in the 2nd workspace and check it in, thus creating a parallel version. I can deliver it. And now I would have problems with, say, a binary file. All this leads me to think that the lock is personal and doesn't result in the file being unmodifiable in all workspaces in the stream, but only in others' workspaces. This is probably not right: the lock should mean the file cannot be changed in any other workspace, even my own. One more question: Is it possible to force locks in a stream? That is, to achieve the equivalent of UCM single-stream project with no unreserved checkouts? This would be a good feature for, say, document development (unless you're smart enough to be using XML!). |
4 answers
Your proposed workflow sounds like the direction we would like to move
towards. Just some comments to wrap up this thread but we can post to the bug if there's anything more to discuss. 1) Marking files is an idea we have brainstormed about. Implementing it would first require a team-preference mechanism of how these files settings are saved, and we have to work out the details of the team dynamics there. (Permissions, roles, etc...) 2) RTC currently has this type of awareness. 3) Preventing the user from editing the file locally is a next step. There are some workflow details like what happens when a user switches flow targets - how does that affect his local-write-access, and other implementation details to examine. 4) Forced unlocking for admins exists when an administrator tries to unlock a lock (that he does not own) from the search view. On Mon, 10 Aug 2009 08:08:02 -0400, David.Sedlock.infineon.com <David> wrote: Maybe we should back up and look at the problem rather than the -- |
Maybe we should back up and look at the problem rather than the solution.
The standard workspace workflow in RTC is rightly aimed at parallel development. But if you are developing binary files - an example would be Framemaker documents - you can't work like this. You need more than "raised awareness". You need a sequential workflow, at least with respect to a stream (probably not with respect to all streams, since even documents may need bug fixes). It's clear to me that RTC locks are not supposed to be the solution here. I think the solution would be something like this: 1) A project can associate file extensions with an attribute that indicates sequential development in a stream is mandatory. In addition, individual files can be so marked. 2) Once such a file is modified in a workspace, it appears in all workspaces flowing into the stream as "reserved" by the person who is changing it. 3) To start modifying such a file, the following conditions must obtain: a) it cannot be reserved and b) the version in the workspace must be the latest in the stream. (That is, changes by others must have been delivered to the stream and accepted in the workspace.) 4) There is some escape mechanism in case a file is incorrectly reserved (e.g. someone is gone on holiday). For example, a project admin can cancel the reservation. -David |
Geoffrey Clemm (30.1k●3●30●35)
| answered Aug 07 '09, 12:07 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Note: The work item requested support for "only you can modify a locked
file" is 77416: "Prevent editing a file when it is locked by another user". Please feel free to add your comments/support for that work item. Cheers, Geoff Andrew Hoo wrote: Locks are held by users on resources in particular streams (not |
Locks are held by users on resources in particular streams (not repository
workspaces). So there are a few things going on with your scenario: If you are working with two workspaces belonging to you (the same user), then your locks on the target stream do not discriminate between where changes are coming from (workspace1 vs workspace2). Only that your user owns the lock and thus you are allowed to deliver to that stream. So in workspace1, you can create an outgoing change set (with a blue lock owned by 'me') and deliver it freely. In the 2nd workspace, you will then see that as an incoming change, still with a blue lock (owned by 'me'). But if you were to login as somebody else (lets say: Bill), then Bill would see your incoming change as a red decorated lock (owned by David). When the doc says "only you can modify a file...", it really should say, only you can deliver to the stream in which you have the lock. Everybody is always free to edit their own file in their own repository workspaces because you don't even know that they intend to deliver to the stream that you own the lock. Maybe Bill wants to fork and deliver to a different stream that you do not care about. You have only declared that Bill cannot deliver to the stream in which you have the lock. That being said, the locks do not prevent you from potentially creating a conflict case that needs to be merged. They're meant to raise awareness of who's working on what, and prevent people from racing to deliver their changes to the stream first. Once you have released the lock, Bill might be happy to do the merges and deliver after you (assuming it wasn't a difficult binary file that you locked). So considering that people may be delivering to different streams, or that people can do merges and still want to work while locks are held, I don't believe locking the file in everybody's repository workspace (even your own) is correct, and that this currently works as intended. (feel free to open up an enhancement if I haven't convinced you.) I'm unfamiliar with how UCM works with 'forced locks with no unreserved checkouts', but if I'm reading you correctly, I think you mean that a lock is automatically taken by you in a stream when you start editing it. That feature is not currently implemented but it is one that we have thought about and would like to implement when we've flushed out the details. On Fri, 07 Aug 2009 07:23:02 -0400, David.Sedlock.infineon.com <David> wrote: I have tried out locking a file as follows, working with two -- |
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.