Re: Communication of LOCKS and CHANGES

kmradke@rockwellcollins.com wrote:

>> The part that I don't get is why you don't set needs-lock if your intent
>
>> is to communicate the fact that changes to a file will be difficult or
>> impossible to merge even if this is a temporary situation. This is what
>
>> should tell others that they need to be concerned about locks, whereas
>> the temporary existence of a lock has no such meaning even though you
>> might think it does and you might sometimes be right.
>
> Hmmm... That would force the users to update their working copy to get
> the (temporary) needs lock property change.

Yes, but it can be set ahead of time without much harm, as soon as the
decision is made to make this unusual hard-to merge change and it won't
disappear accidentally if you commit part of the revision. If users
aren't updating frequently they should expect to have hard to merge
conflicts in their work anyway.

> It may be incorrect, but I have users that assume when the "get lock" is
> done on a non needs:lock file, others are made aware of this. This
> is probably a side effect of having more with ClearCase backgrounds
> instead
> of CVS backgrounds...

They are 'made' aware if they try to commit against a locked file and
they can check if a lock exists if they want, but the normal assumption
for a file without needs-lock would be that you'd be able to merge
concurrent changes and don't need to be concerned.

> I suppose I could write a hook script to disallow locks on non needs:lock
> files indicating the user needs to add the property before trying the
> lock,
> but users hate these multi-step processes.

I'd hope that needing to lock files that aren't already marked
needs-lock would be an unusual situation.

> I would like to still see the CHANGED status cached if possible, since
> there seems to be much less objection to this issue.

Didn't someone say that one or more of the GUI clients already does that?

-- 
   Les Mikesell
    lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org