On Mar 14, 2005, at 3:37 PM, Ben Collins-Sussman wrote:
>
> On Mar 14, 2005, at 2:27 PM, John Peacock wrote:
>>
>> I'm actually with Greg that if the system is slow for people who
>> insist on locking everything in sight, it's not such a bad thing
>> ("operant conditioning" is the phrase I'd use). I'm just trying to
>> make sure we can legitimately withstand the "Your software sucks"
>> e-mails from people who scale up locks to their entire repository.
>>
>
> In the VSS world, it's the norm for 'owners' of components to keep
> their modules permanently locked; it's the default state. These are
> the folks who will most likely be wanting/trying to lock whole
> directories at a time.
>
Having come from VSS I can say that this is not the "default state" for
any place I have worked. It is an option in VSS to have 'exclusive
checkouts', which, when set, means that only one person can have write
access to a file at any one time. Normally however, the same file can
be modified by multiple people (the locking is not exclusive to one
developer). VSS makes a distinction between a "get" and a "checkout",
normally you "get" all the files, but only "checkout" the ones you will
modify. A checkout makes the files writable, otherwise the normal
state for files is read-only.
The point being most VSS users I am aware of only "checkout" the
handful of files that they really do intend to modify, not a whole
tree. This is regardless of the locking/multiple checkouts setting.
In fact the Visual Studio IDE (the defacto standard for Windows
developers) automates the process so that you are asked to checkout a
file the moment you attempt to change that file.
The one thing that people coming from VSS might want is "shared locks",
i.e. the read-only behavior that they are used to, but the ability for
multiple people to work on a file simultaneously, without resorting to
making all the files writable all the time. But that's another
discussion entirely.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 14 22:18:33 2005