Ben Collins-Sussman wrote:
>
> On Nov 16, 2004, at 2:13 PM, Esteban Bolanos wrote:
>
>> In the case I exposed, the purpose of checking out files in
>> read-only mode
>> is to keep users from doing accidental changes in files they shouldn't
>> change and then commiting those changes without noticing; it is not about
>> obtaining exclusive locks on files.
>
>
> That's a fascinating use-case. I've never heard of any group using 'cvs
> edit/watch' to solve this problem. Actually, I've never heard any group
> of developers say that "accidentally editing and committing files" was
> *ever* a problem!
I worked in a team using PowerBuilder with VisualSourceSafe and this was
exactly the policy. (Indeed IIRC what VSS does is exactly this: having a
read-only copy of the repository in each computer and write-allowing the
files you check-out).
This was seen as a big advantage because those "magic" operations as
'regenerate' and 'optimize' in PB can modify a lot of files if you make
a mistake.
> But I do believe you. You have to forgive others for jumping to the
> locking assumption; by far and away, most of the planet uses 'cvs
> edit/watch' as a way to deal with unmergeable files. It sort of solves
> the same problem that locking does, and that's what most people use it for.
>
> Regarding locking: we're actively working on that feature now. It's
> been designed and re-designed and discussed for the last two months.
> There are all sorts of documented plans on how we're doing it, in the
> notes/locking/ area. And I've been coding the BDB implementation all
> last week and this week. As a group, svn's developers aren't morally
> opposed to the idea of locking: we understand that some files are
> unmergeable, and that a locking feature solves an important problem.
>
> Unfortunately, we have no plans to emulate the CVS read-only feature
> you're talking about. In SVN's upcoming design, a read-only file means
> "it must be locked to be edited". There's no read-only concurrent files.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 17 09:49:17 2004