On Apr 4, 2005, at 5:02 PM, Brooke Smith wrote:
> Hi Ben,
>
> The two step process is 1. User wants to edit file, 2. User opens file
> but finds its read-only (confusion possibly reigns) 3. If they
> understand the issue they issue they lock the file and edit it. Step
> 2 may not occur. The 2 step process is lock and edit.
>
> I was thinking about this from the documentation teams POV (or the
> graphic illustrators). The non-techo types basically. These people
> might think that they just want to edit the file, not take this extra
> step which they don't understand. I answered my own question in my
> last mail and said that the client, such as TortoiseSVN could provide
> the option and automatically set the lock before opening files that
> have that property attached.
>
Sorry, I'm still not understanding. How can step 2 not occur? They're
not going to notice that the file is read-only? That's certainly
possible... there are bad programs out there which flat-out ignore
read-onlyness. We call that 'hijacking'.
But the problem is that *nothing* can prevent hijacking, not even your
TortoiseSVN idea above. The only thing that can prevent it is if the
working-copy were implemented at the OS filesystem level -- and that's
how clearcase works. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Apr 5 03:24:08 2005