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

Re: [Issue 533] New - implement reserved checkouts

From: Dave Cridland <dave_at_cridland.net>
Date: 2002-08-05 14:37:58 CEST

On Mon, 2002-08-05 at 09:27, Greg Stein wrote:
> Oh, geez. This whole thread is way too narrowly scoped. *Everybody* is
> talking about developers and source code. Fine, geez. No locks.

Absolutely, and I 100% agree with the rest of Greg's email, too.

I foresee a time in the not too distant future when I'll be installing
Subversion as an "office shared filesystem", in a purely
non-development, non-project managed, environment.

Moreover, I foresee that this is a significantly larger market.

In this environment, not only are the majority of files going to be
non-merge-able in the short term (XML based file formats hopefully in
the long term), but the users are not going to be expected to have the
technical savvy to deal with a failed merge, even if merges were

They may well not have the savvy to accept that when some GUI somewhere
tells them "Hey, this file is locked by someone@somewhere.else, do you
want to screw them up totally and grab the lock off them", then
answering "yes" might be a truly bad thing. There may not even be a GUI
- probably not, actually, given the DAV/Web Folder sutff.

Mandatory locks need to be available as a tool to prevent damage and
loss of data in this use of Subversion.

Of course, the users can always copy the file locally, and fork it that
way, but equally they can run into the server room with a large axe and
start swinging wildly. Breaking mandatory locks is something they have
to consciously decide to do, as is axe-swinging, one would hope.

Advisory locks would be, I'm sure, useful in other circumstances,
although to be fair I can't think of any.

I agree with the general consensus that they're a false security, and
should not be used, for source code, but as I stated earlier, I
sincerely doubt that source code will be the largest market, and
moreover one hopes that users working on source code are relatively
technically aware.

Comments and flames both welcome.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Aug 5 14:35:45 2002

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

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