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

Re: [Issue 533] New - implement reserved checkouts

From: Karl Fogel <kfogel_at_newton.ch.collab.net>
Date: 2002-08-01 23:42:46 CEST

Greg Stein <gstein@lyra.org> writes:
> Personally, I don't :-) I'm not a fan of creating a new revision simply
> because somebody took out a lock on something they *might* change (they
> could revert and cancel their lock). Also, I believe the typical pattern of
> behavior is that a person will incrementally take out their advisory locks
> as they discover they need to change <whatever> files.

I'm not understanding how the second sentence above is incompatible
with the proposal...

> Locking is evil *only* when you have documents that can easily be merged.
> Locking is an absolute must for things like .doc or .xls files. Two people
> cannot work on those at the same time, and merge their changes later. Thus,
> it is a requirement to have a lock.

Why? For non-mergeables, it's still *communication* that's the
necessity. After all, neither set of changes need be lost in case of
a conflict. And one set of changes could simply never be started, if
they have communication.

I don't see the requirement for a lock at all here.

Put it this way: you say

   "Two people cannot work on those at the same time"

...so Subversion should make it easy for them to avoid working on
those two things at the same time. Locks are not the only way to do

> My thinking has been along this line:
> * the server has a CGI script that manages a DB of locks
> * a start-commit hook tosses anybody that doesn't hold a lock
> * a pre-commit hooks tosses commits to items that are not locked by the
> commiter (read: you must lock everything before committing)
> * a post-commit hook clears locks on items which were committed
> * a client-side tool interacts with the CGI to:
> - establish a lock
> - remove a lock
> - list existing locks
> - break locks
> * the CGI is also responsible for sending emails

That would work too. Not sure which is more complex internally; but
the need for a separate client side tool is a bit of devel overhead...

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 1 23:57:41 2002

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.