Lets look at this from a different perspective.
A tool like TSVN may work like this:
1. The user ticks a preference to say yes to 'always lock file for
writing'. The preferences are of course global and the user never has
to venture here again.
2. User tries to open the 'needs-lock' file
3. TSVN locks the file (if it isn't already and in which case it will
display an error message) and opens the file. The user isn't aware.
The alternative and error-filed / confusing view of this is:
The user is using the SVN command-line tools
1. The user in a terminal creates a WC with 'svn co svn://....'
2. User tries to open the 'needs-lock' file and it opens (read only)
3. Depending on the user's skill level, they may either be confused or
issue a "Doh!" (or be frustrated that they didn't know it was marked
'needs-lock')
In the first scenario, the Client tool is protecting the user. In the
second scenario, the svn command-line tools are much lower-level and
would never auto-lock a file. I guess the Developer's view on this is
that those who use the CL client will be aware of the problem
immediately. But maybe not, since authorisation may also make a
resource read-only.
My point here is that a higher-level client like TSVN may gracefully
handle the 'needs-lock' property but that the lower-level CL client
won't and there should be some appropriate feedback mechanism to
highlight the fact that the file is marked 'needs-lock'.
Brooke
On 05/04/2005, at 11:20 AM, Ben Collins-Sussman wrote:
>
> 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. :-)
>
>
---
In a world without walls or fences,
what's the need for Gates and Windows?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Apr 8 00:53:08 2005