Andrew Vaughan wrote:
>On Thu, 14 Apr 2005 04:51 am, SteveKing wrote:
>>>>- If you don't have the lock, the file is readonly and you can't
>>>Not true, editors are NOT guaranteed to care diddly-squat about
>>>read-only being set.
>>If an editor ignores that flag, that editor is broken. Really!
>But such broken programs exist. From memory notepad write and some
>versions of ms word all have this problem. (I can't check now.)
>They allow you to edit a read-only file without complaining. It is only
>when you try to save the file that you discover the problem.
>It's possible to do hours of work before attempting to save.
Borland Pascal and Delphi also fit this picture. It's a right pain to
have edited a file and not noticed the read-only flag before hand. So
for me Explorer is always opened in detailed view. Makes for
quick-n-easy sorting by name, date, type too.
This replay is not targeting Andrew, I'm just taking que from his last
I want to take a step back from the fray for a moment and try to put the
issue of icon overlays for locking into an everyday user's perspective.
The "locking" of files is in reality just a mechanism for groups of two
or more developers to work cooperatively and communicate their immediate
working needs. There is a far bit of discussion going on about how this
group communication should be conveyed.
From my unworldly perspective, unconscious locking should not be
possible. (Don't know if it is)
Where possible, locking should be avoided if another more positive means
of communication can be used. I say that, because the act of locking a
file in the repository does not automatically propagate the fact to all
who may be or become affected. (And the effect can be significant)
To illustrate the above:-
I Open Delphi and it brings up the last project and opens all the last
used files. There is no Explorer view involved in starting up from where
I left off yesterday. Don't expect to remember every file or even which
project was last opened, nor the easy with which we can open past
projects without checking the entire update status either.
Note. The files opened by the editor may be spread across numerous
directories and in turn come from multiple repositories. So, If I
haven't updated everything first, and someone else has meanwhile taken a
lock on a file in the repository then I'm none the wiser. In some ways
it may not matter because I can still save changes locally.
However!!!, if I have updated and I presume this is a recursive process
I may still not see recently locked files change to read-only in
subdirectories and so blithely go about editing, only to fall foul when
I try to save locally. Them I am in trouble and spewing.
I can see this catching and annoying quite a few developers, at
themselves for not noticing and at TSVN or SVN for not being more alerting.
It seems to me, that the locked status for a file deep in a directory
structure should also propagate to the surface just as the modified
status does now.
Regardless of how good the icon overlays are, I feel there will be a
desire for more noticeable other means to "alert" users. TSVN should
only do what it can do but must remain responsive.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Thu Apr 14 04:54:05 2005