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

--

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
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.Sedlock@infineon-dot-com.no-spam.invalid> wrote:

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

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

--