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!
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 07:47:17 2004