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

Re: Atomicity of locks and needs-lock

From: Mark Phippard <markp_at_softlanding.com>
Date: 2006-05-02 16:29:35 CEST

sussman@gmail.com wrote on 05/02/2006 10:20:28 AM:

> Needs #2 is satisfied by *many* possible things:
> * if a file is always unmergeable (say, a graphic), then the
> developers can _proactively_ set the svn:needs-lock property as a
> _permanent_ attribute on the file. This aids communication, by
> keeping the file as read-only 95% of the time; it reminds people to
> lock the file before editing. It's a nothing but a communication aid,
> and an imperfect one at that. (Some programs ignore read-only
> permissions and allow edits anyway.)
> * if a file is mergeable, but somebody wants exclusive control
> anyway, then developers can use phone, email, or whatever out-of-band
> communication they want. "Hey folks, I'm going to lock this file
> today for some critical work I'm doing, please don't edit it." This
> is not a preposterous use-case. It's not a sign of a pathological
> development community. It's perfectly reasonable, once-in-a-while
> behavior.

I will just add that the lock hooks were added to potentially assist with
this as well. And I recall that mailer.py was enhanced to support sending
lock messages if desired. This could assist with communicating locks.

Agree with everything you said.


Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 2 16:30:05 2006

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.