Re: Get exclusive lock

Reedick, Andrew wrote:
>
>> If having svn:needs-lock set really provided that guarantee, this
>> thread
>> wouldn't have started.
>
> Which is the point of the thread. Currently, svn:needs-lock only kicks
> in when:
> a) you app notices the read-only file and communicates that fact
> to the user, or
> b) when you try to commit without a lock, or
> c) when the user explicitly remembers to check for
> svn:needs-lock
>
> a) is weak because not all apps handle readonly files "properly",
> b) is too little too late,
> c) suffers from 'even experts make mistakes' with the added bonus of
> being newbie un-friendly. Plus people who create unmergeable files are
> probably not coders to begin with (pictures, video, audio, etc.) and
> wouldn't even be familiar with the concept of merging.
>
> Hence the desire to add additional notification about, and monitoring of
> 'svn:needs-lock' files by the client.

And my point is that this isn't enough and it won't solve the problem
for people who don't already understand the issue because they won't
know to set it on new files. And if you understand the issue you'll know
to lock files where needed without something that tries to enforce it
(because you know you'd need to set needs-lock on that type of file if
you created it and you know someone else might also be working on it).

>> I'm just not convinced that this mythical "other person" or his tools
>> will be any more observant of a needs-lock status than you are unless
>> he
>> understands the 'guarantee' consists only of your your willingness to
>> cooperate. If you both work at once, one of you is going to lose
>> regardless of how much the tool tries to help.
>>
>
> Agreed. If a knowledgeable person or client was in complete control of
> the situation, then there wouldn't be a problem. However being in
> complete control is impossible unless you either train all your humans
> to be version control experts (and none of whom make mistakes,) or if
> you can force coordination between everyone's OS, their apps, and the
> subversion clients.
>
> So aside from not using unmergeable files anywhere in your organization
> or operating in a police state with total control over everyone's
> computer, the only options are training, and up-front reminders/warnings
> about svn:needs-lock to back-up the training.

Many applications write new files to replace the old as you make changes
and thus don't care if the source has a read-only attribute. You'll
have to replace all of these or write wrappers that generate a warning
(which will only cover the case where you specify the file at startup
instead of using internal functions to open files). Getting the users
to understand the need to cooperate seems like the only real option.

-- 
   Les Mikesell
    lesmikesell_at_gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org