Re: Refresh the member lock

On 7/29/2011 11:28 AM, Mark S. Waterbury wrote:

My main point was and is, whether using SEU, (as in the scenario I
described), or using WDSCi or RDi or RDp, two (or more) developers could
_sequentially_ make changes to the same source member, in rapid
succession, without necessarily being aware that another developer is
also working on the same source member, and each one can then
potentially over-write some (or all) of the other's changes. *:-o*

Well, they would still SEE the other developers work ... if they chose to modify what the other developer had done, then maybe they should be encouraged to find a new job that doesn't need team players. If they are going to to be changing other developers work, then they wouldn't be bothered by any kind of 'advisory lock' that a checkout / checkin mechanism is going to provide. They would simply break the lock and overwrite the other developers code.

The proposed enhancement addresses this issue, and at the same time
eliminates the need for the *EXCL member locks.*;-)*

I disagree ... all it would take is for someone to use a tool that isn't compliant with the proposed mechanism (such as WDSC, RDi, FTP, etc) and source that is under active development would be destroyed.

And an 'advisory lock' is just that ... advisory ... there will have to be a way to break the lock so that some other developer could work on the same source member (albeit not at the same time).

david