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

Re: Communication of LOCKS and CHANGES

From: Les Mikesell <lesmikesell_at_gmail.com>
Date: 2007-11-29 23:43:23 CET

Bicking, David (HHoldings, IT) wrote:

>>> The part that I don't get is why you don't set needs-lock if your
>>> intent
>>> is to communicate the fact that changes to a file will be
>> difficult or
>>> impossible to merge even if this is a temporary situation. This is
>>> what
> You are (effectively) suggesting either:
> 1. Access to that file be serialized as policy (permanent use of the
> property), or

If serializing access wastes less time than conflicting concurrent work,
this would be appropriate.

> 2. To temporarilly lock the file, the user will create at least two
> extra revisions, assuming you know exactly which files need to be locked
> before you act. More likely, several revisions will be generated as you
> realize there are other files that need to be modified. This to me is
> massively inefficient and makes absolutely no sense.

There might be more convenient ways to communicate your intent - like
saying so ahead of time in an email or group meeting/call, but if not,
this seems like the right way to let others know that work on these
files must be serialized for some duration and keep them from wasting
their time. And if you are doing this piecemeal, remember that someone
else could be making their conflicting changes in the opposite order and
never run into your locks.

> Now, given, if the change in question gets beyond two files, it is
> probably worth a task branch. Anything less than that, and a branch is
> overkill.

Branching doesn't really avoid the problem with wasted concurrent work
that can't be merged - it just isolates it for a while.

>>> should tell others that they need to be concerned about
>> locks, whereas
>>> the temporary existence of a lock has no such meaning even
>> though you
>>> might think it does and you might sometimes be right.
> Please explain why the temporary lock feature exists. I thought I knew,
> but I am beginning to suspect I am incorrect.

A lock is an enforcement mechanism, not a declaration of intent. Using
it that way would be like finding out your spouse isn't happy by
noticing that the locks have been changed on your house.

   Les Mikesell
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Nov 29 23:42:41 2007

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.