On 5/2/06, Peter Samuelson <peter@p12n.org> wrote:
> > That is, you would want the needs-lock to have made it out to the
> > rest of the repository users before a lock is obtained.
>
> So, that's a pretty awkward way to work - set a property, _then_
> commit, _then_ lock the file, _then_ start working on your new feature,
> _then_ remove the property, _then_ commit your changes. Is that really
> your recommendation to anyone who wishes to make a
> hard-to-merge-against change to a file?
This thread rather astounds me. I see so many people misunderstanding
this feature, I don't know what to say.
There are two totally independent "needs" here which must be satisfied.
1. the ability for to serialize commits to the repository. The
repository needs the ability to grant exclusive rights to commit
changes to a file.
2. good communication between developers. Developers need to keep
each other in the loop, in order to prevent people from wasting time
on unmergeable changes.
Need #1 is satisfied -- quite simply -- by the 'svn lock/unlock'
commands. End of story.
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.
These two ideas do NOT need to be entangled. They are *independent*
needs and *independent* features. The needs-lock property should have
nothing to do with whether 'svn lock' works or not. Conversely, using
'svn lock' should not have any affect on the property's existence.
One feature reserves exclusive access, the other is an optional
communication aid. The features can be used independently or
together, but ultimately there's no substitute for true out-of-band
communication.
---------------------------------------------------------------------
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:20:57 2006