>> I am not sure why your are focusing on files with the locked
>> status in the cache (false positives.) They are not the
>> problem at all. The developer will see that they were locked
>> at one time and figure out whether they are still locked and
>> do the right thing.
>>
>> It is the false negatives that will cause the problems. The
>> developer will look at his working copy see no lock and start
>> modifying the file.
>> Only later he'll find out it's locked. That's when you have a problem.
>>
>>
>
> And, this is how things are right now. This problem exists and is
> unaffected by presenting more information to the user. However, the
> other problems are deminished. Also, this problem becomes less likely
> if the developer has a habit of updating before beginning new work, say
> when she comes into the office in the morning, or after lunch.
>
>
>
>
I don't understand how you can communicate that a file is/was locked
without giving people the impression that files that are not listed as
locked are unlocked.
I really don't understand how locking is useful unless you require
someone to lock a file before they edit it. But then I guess I don't
need to understand. You should be able to write a script that caches the
information. You can run that instead of svn status.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Nov 26 20:18:37 2007