[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Checkout every file as read-only; make some of them editable with a explicit command.

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2004-11-17 07:46:22 CET

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

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

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

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.