Justin Erenkrantz wrote:
> 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.
- Without lock, there will be a merge conflict in the other guy's
working copy, because of your commit.
- With a lock but rw wc file, there will be a merge conflict
in your working copy because you changed the file locally.
- With a lock but read-only wc file, there won't be a merge conflict at all,
because you were not able to modify the file.
Agreed, there may be cases that you might still want to change your
file locally even if someone else has a lock.
Similar to stealing a lock.
But you can simply change the file attribute for that,
so I don't see a problem.
I think the main reason for locks is to avoid (unmergable) conflicts,
and a read-only wc file is important for that.
If you and others don't want/need write protection,
an option may be the right choice.
But I am sure that if locking does not support read-only wc files at all,
this would be a fundamental flaw.
Cheers,
Folker
>
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 13 12:24:09 2004