Re: Locking functional spec: timeouts

Justin Erenkrantz wrote:
> ...
> Yet, this is going to introduce a whole set of goofiness: locks may not
> necessarily have to be 'unlocked' - they can just expire. Ideally, we'd
> go for a lazy expiration model. And, lots of other things need to be
> thought about timeouts as well from a user perspective.
>
> What do the rest of ya'll think? -- justin

Well, when it comes to locks I think the default should be no timeout,
but provide an option to specify one. In most cases, I think people
will be locking unmergeable files and plan on changing something and
then committing. As long as we provide a way to break locks, the
timeout won't normally be needed.

That said, it also would probably be useful to be able to set the
default lock timeout as a file/directory property (perhaps limiting
the scope of directory preferences to immediate children) for
environments/apps which want/need timeouts.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Printing Software for UNIX                       http://www.easysw.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org