You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Justin Erenkrantz <ju...@erenkrantz.com> on 2004/10/15 05:08:08 UTC
Locking functional spec: timeouts
Over in the 'Locking UI comments', Julian R. and I had a conversation about
Microsoft Office's WebDAV LOCK support and some bugs in it. There's a
development in here that now needs to be explicitly considered, so I'm
splitting this out into a new thread.
Here's the latest of what Julian said in case you missed it:
--On Thursday, October 14, 2004 7:25 PM +0200 Julian Reschke
<ju...@gmx.de> wrote:
> OK, I just checked with Office 2003; it attempts a LOCK with 180s timeout;
> if the request suceeds but the timeout sent back by the server isn't what it
> expects, it gives up and opens the document read-only. Furthermore, it
> doesn't UNLOCK the document when it's closed. (Yes, that is a bug in Office;
> clients MUST NOT rely on servers supporting specific timeout values, see
> <http://greenbytes.de/tech/webdav/rfc2518.html#HEADER_Timeout>).
>
> So it seems that adding locking functionality without timeout support will
> not help for the MS-Office use case.
So, if we don't support timeouts, Office/Word will refuse to play ball. And,
part of my ideal for LOCKing is to get Office users happy. However, it
changes some parts of our locking UI (some significantly). So, first, before
going down that road, is it important enough to support locking with Office
and a Subversion server that we add timeouts?
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec: timeouts
Posted by Julian Foad <ju...@btopenworld.com>.
Michael Sweet wrote:
> Justin Erenkrantz wrote:
>> What do the rest of ya'll think? -- justin
>
> Well, when it comes to locks I think the default should be no timeout,
[...]
> That said, it also would probably be useful to be able to set the
> default lock timeout as a file/directory property (perhaps limiting
Hold on. I don't think there's any need for lock timeouts to be
supported at all by our Subversion client; at least, that's a separate
issue. I think Justin was just talking about the need for our DAV
server to support them in order to play nicely with certain
non-Subversion clients.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec: timeouts
Posted by Michael Sweet <mi...@easysw.com>.
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
Re: Locking functional spec: timeouts
Posted by Julian Reschke <ju...@gmx.de>.
Justin Erenkrantz wrote:
> Over in the 'Locking UI comments', Julian R. and I had a conversation
> about Microsoft Office's WebDAV LOCK support and some bugs in it.
> There's a development in here that now needs to be explicitly
> considered, so I'm splitting this out into a new thread.
>
> ...
>
> So, if we don't support timeouts, Office/Word will refuse to play ball.
> And, part of my ideal for LOCKing is to get Office users happy.
> However, it changes some parts of our locking UI (some significantly).
> So, first, before going down that road, is it important enough to
> support locking with Office and a Subversion server that we add timeouts?
>
> ...
It's not only a question of making Office users happy. They *will* open
documents from Subversion, see them opening as "read-only" and possibly
will not care. However, Office will have created a LOCK on their behalf
that will never get UNLOCKed by Office, so manual intervention of
*somebody* will be required to get rid of it.
Julian R.
--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec: timeouts
Posted by Mark Benedetto King <mb...@lowlatency.com>.
On Thu, Oct 14, 2004 at 10:08:08PM -0700, Justin Erenkrantz wrote:
> Over in the 'Locking UI comments', Julian R. and I had a conversation about
> Microsoft Office's WebDAV LOCK support and some bugs in it. There's a
> development in here that now needs to be explicitly considered, so I'm
> splitting this out into a new thread.
>
> Here's the latest of what Julian said in case you missed it:
>
> --On Thursday, October 14, 2004 7:25 PM +0200 Julian Reschke
> <ju...@gmx.de> wrote:
>
> >OK, I just checked with Office 2003; it attempts a LOCK with 180s timeout;
> >if the request suceeds but the timeout sent back by the server isn't what
> >it
> >expects, it gives up and opens the document read-only. Furthermore, it
> >doesn't UNLOCK the document when it's closed. (Yes, that is a bug in
> >Office;
> >clients MUST NOT rely on servers supporting specific timeout values, see
> ><http://greenbytes.de/tech/webdav/rfc2518.html#HEADER_Timeout>).
> >
> >So it seems that adding locking functionality without timeout support will
> >not help for the MS-Office use case.
>
> So, if we don't support timeouts, Office/Word will refuse to play ball.
> And, part of my ideal for LOCKing is to get Office users happy. However,
> it changes some parts of our locking UI (some significantly). So, first,
> before going down that road, is it important enough to support locking with
> Office and a Subversion server that we add timeouts?
>
> 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
>
Why not have the libsvn_client request locks that last a long, long
time (effectively permanent)?
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec: timeouts
Posted by Branko Čibej <br...@xbc.nu>.
Daniel Patterson wrote:
> Greg Hudson wrote:
>
>> Not really. I think they'd be more likely to appreciate a locking
>> system which didn't confuse them by talking about features like expiry
>> which they don't need.
>
>
> I think you underestimate the forgetfulness of the Junior Programmer!
Not at all, and junior programmers aren't the only culprits. I've given
a piece of my mind to many a "senior" programmer about this any number
of times. But this is a team management issue that can't be solved by
adding useless features to a version control tool.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec: timeouts
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Ben Collins-Sussman wrote:
> Hm, I suppose you're right. Maybe this means that lock expiration needs
> to be a 'core' feature in libsvn_repos, common to all RA accesses. But
> we still don't have to expose that feature on the client side.
Yeah, that's what I'd like to see.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec: timeouts
Posted by Branko Čibej <br...@xbc.nu>.
Ben Collins-Sussman wrote:
>
> On Oct 20, 2004, at 3:39 PM, Garrett Rooney wrote:
>
>> Ben Collins-Sussman wrote:
>>
>>> So I suppose mod_dav_svn can have another private db table (like the
>>> activities.db) which can store lock-expiration times. Whenever a
>>> client mentions a lock, mod_dav_svn can compare the lock-expiration
>>> time (if it exists) with the lock's creation timestamp, and
>>> "auto-release" the lock.
>>
>>
>> That doesn't work so well for repositories that can be accessed by
>> more than one RA layer. Someone takes out a 5 minute lock over
>> mod_dav_svn, then nobody ever uses the http:// interface again, the
>> lock stays there forever, or at least until someone breaks it
>> manually. That doesn't seem right...
>>
>
> Hm, I suppose you're right. Maybe this means that lock expiration
> needs to be a 'core' feature in libsvn_repos, common to all RA
> accesses. But we still don't have to expose that feature on the
> client side.
In libsvn_(repos|fs), but /not/ in the RA layers. That's the whole point.
We need it in the repos/fs layer so that mod_dav_svn can set the
timeouts and so that they get cleaned up automagically, but even ra_dav
shouldn't issue lock requests with timeouts. We'll support lock timeouts
in mod_dav_svn for non-Subversion clients, such as MS Office. No
Subversion client should ever issue such a request.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec: timeouts
Posted by Ben Collins-Sussman <su...@collab.net>.
On Oct 20, 2004, at 3:39 PM, Garrett Rooney wrote:
> Ben Collins-Sussman wrote:
>
>> So I suppose mod_dav_svn can have another private db table (like the
>> activities.db) which can store lock-expiration times. Whenever a
>> client mentions a lock, mod_dav_svn can compare the lock-expiration
>> time (if it exists) with the lock's creation timestamp, and
>> "auto-release" the lock.
>
> That doesn't work so well for repositories that can be accessed by
> more than one RA layer. Someone takes out a 5 minute lock over
> mod_dav_svn, then nobody ever uses the http:// interface again, the
> lock stays there forever, or at least until someone breaks it
> manually. That doesn't seem right...
>
Hm, I suppose you're right. Maybe this means that lock expiration
needs to be a 'core' feature in libsvn_repos, common to all RA
accesses. But we still don't have to expose that feature on the client
side.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec: timeouts
Posted by Mark Phippard <Ma...@softlanding.com>.
Garrett Rooney <ro...@electricjellyfish.net> wrote on 10/20/2004 04:39:22
PM:
> Ben Collins-Sussman wrote:
>
> > So I suppose mod_dav_svn can have another private db table (like the
> > activities.db) which can store lock-expiration times. Whenever a
client
> > mentions a lock, mod_dav_svn can compare the lock-expiration time (if
it
> > exists) with the lock's creation timestamp, and "auto-release" the
lock.
>
> That doesn't work so well for repositories that can be accessed by more
> than one RA layer. Someone takes out a 5 minute lock over mod_dav_svn,
> then nobody ever uses the http:// interface again, the lock stays there
> forever, or at least until someone breaks it manually. That doesn't
> seem right...
Maybe I differ with ghudson on this, I am not sure. Assuming we need to
support lock timeouts for DAV, then I would think that the lock "database"
for lack of a better term, would need to include an expiration date/time.
When any client, other than DAV, acquired a lock, the date/time would be
some "permanent" date like 12/31/9999. When any code, regardless of UI,
checked the database to see if a file were locked, it would always
consider the expiration date/time. So DAV locks could expire in any UI
without needing a daemon to get rid of them.
I wouldn't consider this "polluting" the code base, although I do not know
enough to know the impact, and it leaves the door open to create a UI for
setting the expiration in the future from the svn client. Although, I
still see little value in that. If this has to be supported for DAV,
though, I agree the lock ought to be supported properly in all UI.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec: timeouts
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Ben Collins-Sussman wrote:
> So I suppose mod_dav_svn can have another private db table (like the
> activities.db) which can store lock-expiration times. Whenever a client
> mentions a lock, mod_dav_svn can compare the lock-expiration time (if it
> exists) with the lock's creation timestamp, and "auto-release" the lock.
That doesn't work so well for repositories that can be accessed by more
than one RA layer. Someone takes out a 5 minute lock over mod_dav_svn,
then nobody ever uses the http:// interface again, the lock stays there
forever, or at least until someone breaks it manually. That doesn't
seem right...
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec: timeouts
Posted by Ben Collins-Sussman <su...@collab.net>.
Okay, I give in. :-)
It's really a question of "what's uglier?"
* putting a lock-expiration feature into core libraries.
* making only mod_dav_svn implement lock-expiration.
I feel that code-wise, if you're going to implement a feature, you
should implement it everywhere: libsvn_repos, commandline client, and
so on. I hate the ugliness of features specific to RA layers.
But if this a feature that nobody wants or cares about, and serves only
to pollute/complicate our UI, then heck, I guess that's at least as
ugly a situation.
So I suppose mod_dav_svn can have another private db table (like the
activities.db) which can store lock-expiration times. Whenever a
client mentions a lock, mod_dav_svn can compare the lock-expiration
time (if it exists) with the lock's creation timestamp, and
"auto-release" the lock.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec: timeouts
Posted by Mark Phippard <Ma...@softlanding.com>.
Greg Hudson <gh...@MIT.EDU> wrote on 10/19/2004 07:32:26 PM:
> (Just in case anyone's lost track, I'm not opposed to implement lock
> timeouts at all; we need them for good DAV support. I'm opposed to
> making them visible via the command-line client, the libsvn_client or
> libsvn_ra APIs, or the ra_svn protocol.)
I am sure you all will make the right decisions as to whether lock
timeouts will exist anywhere other than DAV, I would just like to chime in
that I do not see any value in having this feature, especially if it
overly complicates things. If you have to implement the feature anyway
for DAV, and it wouldn't be hard to support it everywhere else too, well,
like I said, I am sure you will make the right decision.
I have worked with several locking version control systems, and I have
never encountered one that had this feature, nor can I imagine why it
would be desired. The argument that it is because people go on vacation
and forget to check stuff back in is totally bogus as there obviously has
to be a system in place to break the locks anyway. Not to mention that
they may still have legitimate changes that should be committed.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec: timeouts
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2004-10-19 at 17:35, Daniel Patterson wrote:
> Greg Hudson wrote:
> > Not really. I think they'd be more likely to appreciate a locking
> > system which didn't confuse them by talking about features like expiry
> > which they don't need.
>
> I think you underestimate the forgetfulness of the Junior Programmer!
No... but I wouldn't expect them to use lock timeouts either. And I
would expect that, in environments where people lock things and forget
to unlock them, the system would be configured to allow people to steal
each other's locks.
Just because we can imagine someone setting up a repository such that
people can't get work done in it is not an excuse to keep adding feature
after feature to mitigate the harm.
> Perhaps lock expiry can be turned on as a file property,
> like 'svn:lock-expiry-time' or something (make it optional, or
> default to "-1").
Now you want to complicate the system even more, by making lock expiry
times depend not just on the lock request (which is how it works in DAV)
but also on repository properties.
We have a responsibility to help people do what they want, but we also
have a responsibility to keep things simple by not providing features
which only a tiny fraction of users would use.
(Just in case anyone's lost track, I'm not opposed to implement lock
timeouts at all; we need them for good DAV support. I'm opposed to
making them visible via the command-line client, the libsvn_client or
libsvn_ra APIs, or the ra_svn protocol.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec: timeouts
Posted by Daniel Patterson <da...@danpat.net>.
Greg Hudson wrote:
> Not really. I think they'd be more likely to appreciate a locking
> system which didn't confuse them by talking about features like expiry
> which they don't need.
I think you underestimate the forgetfulness of the Junior Programmer!
People *are* going to lock things they don't need to lock, in
great swathes across their WC's. Then, they're going to make one
or two changes, commit those files and unlock *just those files*,
leaving everything else locked.
Then, they're going to go on vacation.
Heck, where I work, people
constantly (after at least a couple of years of begging, pleading
threatening, etc) commit files one at a time, commit debugging code,
files specific to their personal environment, temp files, object
files, etc.
I think it's reasonably sensible to at least have the ability for
the repository to slowly (as locks expire) restore itself to a state
where everyone can work again. Sure, the admin can break locks
(or maybe users can too, depending on policy), but if the admin
is away, and the policy is "users can't break locks", then having
locks expire may be a saving grace.
I think lock expiry is a counter-measure for users who don't
communicate sufficiently. It makes their lack of communication their
problem, not everyone elses (i.e. they have to deal with the
conflicts and apparent hijacks when they return from vacation,
which is their own fault for leaving locked files and walking out).
Perhaps lock expiry can be turned on as a file property,
like 'svn:lock-expiry-time' or something (make it optional, or
default to "-1").
daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec: timeouts
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2004-10-19 at 13:13, Ben Collins-Sussman wrote:
> You can't envision a scenario of a team using svnserve, using locks,
> and appreciating a lock-expiration feature?
Not really. I think they'd be more likely to appreciate a locking
system which didn't confuse them by talking about features like expiry
which they don't need.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec: timeouts
Posted by Branko Čibej <br...@xbc.nu>.
Ben Collins-Sussman wrote:
> You can't envision a scenario of a team using svnserve, using locks,
> and appreciating a lock-expiration feature?
>
> Sure, the idea of lock-expiration was originally motivated by the DAV
> spec and MS Word DAV clients, but that doesn't mean it's automatically
> some crazy HTTP-specific feature being ickily shoehorned into
> Subversion. It seems like a useful feature to me, even if mod_dav_svn
> didn't exist.
No, I can't envision such a scenario. The DAV locking feature was not
designed with version control in mind. IMHO, in version control, lock
expiration is evil, because if you've locked and changed a file, you
_don't_ want your lock to expire before committing. Sure, there are
situations where explicitly breaking a lock is necessary; but I can't
see how it makes sense to do that automatically.
Supporting lock expiration in the DAV layer is necessary; I definitely
do _not_ want to support it in other layers. If supporting it for DAV
means that the lock timeout must somehow be recorded in the repository,
that's marginally acceptable. But I'd probably veto adding such knobs to
the UI or the RA layers at this point; it's unhygienic.
*If* it turns out someday that lock expiration is a useful feature in
general, then sure, we can add support for that in the RA interface. But
I'd have to see much stronger arguments in favour of it than I've seen
to date.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec: timeouts
Posted by Ben Collins-Sussman <su...@collab.net>.
On Oct 19, 2004, at 10:32 AM, Greg Hudson wrote:
> On Tue, 2004-10-19 at 11:06, Ben Collins-Sussman wrote:
>> I don't understand: what's wrong with supporting lock timeouts as a
>> 'core' locking feature in the libsvn_repos (or fs) libraries?
>
> When there's a feature you don't really want for yourself, but which
> you
> have to support for the user of module X, it's good to look for a way
> to
> implement it wholly within module X, so that you don't pollute your
> core
> with stuff only module X cares about.
>
> Unfortunately, in this case I don't think there's any sane way to do
> that. A well-behaved Apache module does not spawn off a timer process,
> in my world. So we pollute our core a little bit. No big deal.
>
You can't envision a scenario of a team using svnserve, using locks,
and appreciating a lock-expiration feature?
Sure, the idea of lock-expiration was originally motivated by the DAV
spec and MS Word DAV clients, but that doesn't mean it's automatically
some crazy HTTP-specific feature being ickily shoehorned into
Subversion. It seems like a useful feature to me, even if mod_dav_svn
didn't exist.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec: timeouts
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2004-10-19 at 11:06, Ben Collins-Sussman wrote:
> I don't understand: what's wrong with supporting lock timeouts as a
> 'core' locking feature in the libsvn_repos (or fs) libraries?
When there's a feature you don't really want for yourself, but which you
have to support for the user of module X, it's good to look for a way to
implement it wholly within module X, so that you don't pollute your core
with stuff only module X cares about.
Unfortunately, in this case I don't think there's any sane way to do
that. A well-behaved Apache module does not spawn off a timer process,
in my world. So we pollute our core a little bit. No big deal.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec: timeouts
Posted by Ben Collins-Sussman <su...@collab.net>.
On Oct 18, 2004, at 6:29 PM, Branko Čibej wrote:
> No, it's not. I meant that Subversion /qua/ Subversion shouldn't
> support lock timeouts. But mod_dav_svn (not ra_dav!) obviously has to.
>
I don't understand: what's wrong with supporting lock timeouts as a
'core' locking feature in the libsvn_repos (or fs) libraries? As
ghudson suggested, the expiration time can be just another field in the
repository's representation of a lock. When some process -- whether it
be svnserve, apache, or ra_local -- tries to use the lock, or runs 'svn
update', or whatever, libsvn_repos code checks that the lock hasn't yet
expired. If it has, then it throws an error and/or tells the client
that the lock is defunct, and then deletes the lock object.
I don't think we need a special daemon hanging around, trying to delete
expired locks. Expired locks can be detected and tossed "lazily", only
when something lists or examines them.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec: timeouts
Posted by Branko Čibej <br...@xbc.nu>.
Greg Hudson wrote:
>On Mon, 2004-10-18 at 19:12, Ben Collins-Sussman wrote:
>
>
>>On Oct 18, 2004, at 6:02 PM, Branko Čibej wrote:
>>
>>
>>>I'd even consider implementing lock timeouts as something mod_dav_svn
>>>handles itself, so that the repopsitory wouldn't have to know about
>>>lock timeouts at all.
>>>
>>>
>>>
>>I don't think we should be designing locking for only one RA layer.
>>
>>
>
>I don't think that's what Branko meant,
>
No, it's not. I meant that Subversion /qua/ Subversion shouldn't support
lock timeouts. But mod_dav_svn (not ra_dav!) obviously has to.
> but I don't see how we can do
>what he says unless mod_dav_svn can somehow pop up three minutes after
>the lock request and nullify the lock.
>
>(To put it another way: if I use mod_dav_svn to request a lock which
>expires after three minutes, and then I use ra_local to attempt to
>commit to the file five minutes later, that commit needs to succeed.
>Which means either mod_dav_svn did something active three minutes after
>the lock request, or ra_local knows something about lock expiry.)
>
>
Yes, that's what worries me. One solution might be to spawn off a
monitoring process that cleans up the locks (mod_dav_svn can do that
during module initialisation).
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec: timeouts
Posted by Greg Hudson <gh...@MIT.EDU>.
On Mon, 2004-10-18 at 19:12, Ben Collins-Sussman wrote:
> On Oct 18, 2004, at 6:02 PM, Branko Čibej wrote:
> >
> > I'd even consider implementing lock timeouts as something mod_dav_svn
> > handles itself, so that the repopsitory wouldn't have to know about
> > lock timeouts at all.
> >
>
> I don't think we should be designing locking for only one RA layer.
I don't think that's what Branko meant, but I don't see how we can do
what he says unless mod_dav_svn can somehow pop up three minutes after
the lock request and nullify the lock.
(To put it another way: if I use mod_dav_svn to request a lock which
expires after three minutes, and then I use ra_local to attempt to
commit to the file five minutes later, that commit needs to succeed.
Which means either mod_dav_svn did something active three minutes after
the lock request, or ra_local knows something about lock expiry.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec: timeouts
Posted by Ben Collins-Sussman <su...@collab.net>.
On Oct 18, 2004, at 6:02 PM, Branko Čibej wrote:
>
> I'd even consider implementing lock timeouts as something mod_dav_svn
> handles itself, so that the repopsitory wouldn't have to know about
> lock timeouts at all.
>
I don't think we should be designing locking for only one RA layer.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec: timeouts
Posted by Branko Čibej <br...@xbc.nu>.
Ben Collins-Sussman wrote:
>
> On Oct 15, 2004, at 11:54 AM, Greg Hudson wrote:
>
>> On Fri, 2004-10-15 at 01:08, 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.
>>
>>
>> I'm not sure if we have to modify the UI spec at all. The functional
>> spec just needs an optional timeout field associated with a lock. Only
>> DAV locks would ever use it. An svn working copy can assume that its
>> own locks don't time out (since it wouldn't have requested them with a
>> timeout), and other people's locks timing out is the same as other
>> people giving up their locks explicitly.
>>
>> (When accessing the lock table, we would ignore and/or clean up locks
>> with a timeout in the past, of course.)
>>
>>
>
> I agree. This is relatively simple to implement. The svn client
> already needs to be ready to deal with 'defunct' lock tokens. During
> an update, a server may tell a client, "sorry, your token is dead,
> somebody else released it." Or, it may say, "sorry, your token is
> dead, it has expired." No big deal.
I agree.
I'd even consider implementing lock timeouts as something mod_dav_svn
handles itself, so that the repopsitory wouldn't have to know about lock
timeouts at all.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec: timeouts
Posted by Ben Collins-Sussman <su...@collab.net>.
On Oct 15, 2004, at 11:54 AM, Greg Hudson wrote:
> On Fri, 2004-10-15 at 01:08, 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.
>
> I'm not sure if we have to modify the UI spec at all. The functional
> spec just needs an optional timeout field associated with a lock. Only
> DAV locks would ever use it. An svn working copy can assume that its
> own locks don't time out (since it wouldn't have requested them with a
> timeout), and other people's locks timing out is the same as other
> people giving up their locks explicitly.
>
> (When accessing the lock table, we would ignore and/or clean up locks
> with a timeout in the past, of course.)
>
>
I agree. This is relatively simple to implement. The svn client
already needs to be ready to deal with 'defunct' lock tokens. During
an update, a server may tell a client, "sorry, your token is dead,
somebody else released it." Or, it may say, "sorry, your token is
dead, it has expired." No big deal.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking functional spec: timeouts
Posted by Greg Hudson <gh...@MIT.EDU>.
On Fri, 2004-10-15 at 01:08, 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.
I'm not sure if we have to modify the UI spec at all. The functional
spec just needs an optional timeout field associated with a lock. Only
DAV locks would ever use it. An svn working copy can assume that its
own locks don't time out (since it wouldn't have requested them with a
timeout), and other people's locks timing out is the same as other
people giving up their locks explicitly.
(When accessing the lock table, we would ignore and/or clean up locks
with a timeout in the past, of course.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org