[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.

Mark

_____________________________________________________________________________
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.