>Are you using this "timed" locking in your present version control system?
>If so, could you point to on-line documentation for it?
No, I don't know of any systems supporting it. Subversion should fix that,
since this is obviously a good idea ;-)
>I have not come across this idea before and, to be honest, I can't see how
>it could work in a useful way, but if I could read about the full syntax
>(command set) and semantics, that might convince me.
OK... this approach would be extremely useful, at least to our organization.
I think one of the reasons why people like the edit/merge model is that they
never encounter a locked file. However, sometimes locking a resource is
outright necessary, but from my experience people tend to forget to unlock,
even before the weekend (or even before the holidays - this is also an
argument in the SVN book.) All these things Have Happened To Me (tm)
With a lease-based model, this is no longer a problem, at least if there are
some reasonable, configurable defaults.
The point here is... when people are leasing something, they almost always
remembers to return it -or- extend it before it's to late, because there is
a cost involved. The cost here is: If they forget, well, then Subversion
won't accept the commit if someone else has used the lease in the meantime
(there may be other policies around.)
The "forgetting user" has to merge or otherwise resolve the issue manually
when the resource gets available again (e.g. issue a "svn log --lock_audit
<resource>" to see who took the lease, when and remaining time.) Perhaps the
forgetting user has to ask the most current lease-owner to help him merge in
the changes he forgot to commit before it was too late.
"Hey listen, I forgot to... bla,bla,bla... can you please merge paragraph
5.4...bla,bla,bla... I'm sorry, this won't happend again."
With this idea implemented, I would no longer hesitate to add all kinds of
shared "binary documents" to SVN; like Word documents, Powerpoint
presentations, UML files, etc.
>For instance...
>
>Why would a user request a time-limited lock when he can more easily
>request an open-ended lock?
People forget to unlock, and in a distributed environment... that sucks big
time. If the user issues a svn lock without "-t xxx", some reasonable
default lease time should apply.
>Can the same user issue another "lock -t" to extend his lease time, either
>before the time has expired, or immediately after it expires?
Yes, I think one should be able to extend the lease. Also "lock -t 0" would
imply an infinite lease, but perhaps the admin should be able to prevent
that... not sure. Of course, a "svn lock" on a leased resource fails, but
you can still get a read-only copy!
>Does the administrator want to limit the maximum time that can be
>requested?
Perhaps. The default here could be something like 24 hours... this could
even be configurable per resource... I mean, if the lease-policy is part of
the prop-set, the configuration part shouldn't be a problem. If there is no
default for the resource, then a system-wide default applies (or
repository-wide?)
Also: the svn client should, if this idea ever gets implemented, be able to
list all locked files, including remaining lease time / overdue leases (on
both wc and url).
With a graphical GUI, like TortoiseSVN, lease-handling could be even simpler
(i.e. a separate icon overlay for overdue resources or something like that.)
_________________________________________________________________
Last ned nye MSN Messenger 6.0 gratis http://www.msn.no/computing/messenger
- Den raskeste veien mellom deg og dine venner
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Sep 3 19:18:41 2003