> -----Original Message-----
> From: Andy Levy [mailto:andy.levy_at_gmail.com]
> Sent: Monday, March 03, 2008 7:12 AM
> To: Oliver Fabelo
> Cc: users_at_subversion.tigris.org
> Subject: Re: Get exclusive lock
>
>
> You're right - it's "an excuse". You can't use software to solve a
> social or communication problem. Your colleagues need to take
> responsibility for doing their job properly.
>
> How did they not "clobber" each others' work before SVN? It sounds
> like you're doing everything you can form the SVN side with
> svn:needs-lock.
>
> > The worst thing is that they are not mere users, are all computer's
> degree
>
> Some of the most inept computer users I have met are programmers and
> others responsible for keeping computer systems working. As above -
> you aren't alone here.
>
Yes, but you can use software to check for stupid states. If a file is
modified, has 'needs-lock' and lacks a lock, then the software should
flag it. Software is better at detecting such a condition than a human
is. Besides, a 'social or communication' solution would be for the
programmers of the OS, the Applications and the Version Control Software
to work together to protect 'needs-lock' files. Good luck on
implementing that social solution.
'needs-lock' is an important enough issue that the version control
system should be a bit more proactive about it. For example: instead of
relying on an OS level 'readonly' flag or running 'svn proplist -R', why
not add 'needs-lock' to 'svn status'? Any file that is modified with
'needs-lock' and no lock should be flagged as a conflict.
I think people run 'svn status' a lot more often than they run 'svn
proplist -R'. And custom clients are more likely to pay attention to
'svn status' than to properties.
Persionally, multi-tasking, windowed OS clients like TortoiseSVN should
have an option to periodically check for 'needs-lock' files that have
been modified without a lock.
*****
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA622
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-03-03 17:19:01 CET