Re: Locking functional spec: read-only WC

On Wed, Oct 13, 2004 at 10:56:57AM +0200, Folker Schamel wrote:
> In your scenario, the lock is not used to avoid merge conflicts
> of unmergeable files (which I think is the primary job of locks),
> but only to push away the task of merging from me to another person.
> In your particular scenario: The person restructoring the document:
> What about simply finishing their task without lock,
> sending it to management, and then update/merge/commit it?

No: there are race conditions without a lock. A SCM with locking makes
perfect sense in my all-too-common scenario. We don't want to have any lost
updates because it's not possible for Subversion to merge the changes: merging
has to be done by a human. Without a lock, there's human race conditions.

The point of the lock is to prevent anyone from making changes. The question
I fundamentally have is: where are we trying to prevent those changes?

Are we trying to prevent:

- The user from making any local changes
or
- The repository from having any unanticipated changes

I fall on the latter side and that Subversion shouldn't interfere with
whatever the local WC does. Subversion shouldn't be my nanny. -- justin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 13 11:43:52 2004