You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Peter N. Lundblad" <pe...@famlundblad.se> on 2004/12/04 13:28:50 UTC
[locking] out-of-dateness checking during lock
Hi,
I'm starting to design the locking API in svn_client. I presume nobody
else is doing that, please tell me otherwise. The main motivation is that
I want to test ra_svn and that's simpler if we have client support, even
if not complete.
ONe thing I'm not sure about is the out-of-date checking when locking the
path. It is stated in the locking UI design that a path must be up-to-date
when locked. I assume we want to do this atomically.
The current RA API lock function doesn't allow the client to provide a
revision number. We can ask the server for last committed revision of the
path, but that wouldn't atomic. Maybe someone has a plan for how to deal
with this. sussman? fitz?
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [locking] out-of-dateness checking during lock
Posted by Greg Hudson <gh...@MIT.EDU>.
On Sat, 2004-12-04 at 12:21, Michael Brouwer wrote:
> Doesn't this mean that hitting ctrl-c at the right time might leave you
> with
> an out-of-date wc that is holding a lock?
We generally clean up on ^C.
It would be possible to get that situation through unclean termination,
but it would also be possible to get that situation, or ones just as
bad, in a variety of non-ideal circumstances. (For instance, a working
copy which is holding a lock but doesn't know it, or which has given up
a lock but doesn't know it.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [locking] out-of-dateness checking during lock
Posted by Mark Benedetto King <mb...@lowlatency.com>.
On Sat, Dec 04, 2004 at 09:21:21AM -0800, Michael Brouwer wrote:
> Doesn't this mean that hitting ctrl-c at the right time might leave you
> with
> an out-of-date wc that is holding a lock?
>
Yes, but there are several other ways that this can happen (including,
perhaps most likely, "rm -rf wc"). We have a sufficiently powerful
recovery mechanism though: locks can be broken.
http://svn.haxx.se/dev/archive-2004-10/0889.shtml
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [locking] out-of-dateness checking during lock
Posted by Michael Brouwer <mi...@tlaloc.net>.
Doesn't this mean that hitting ctrl-c at the right time might leave you
with
an out-of-date wc that is holding a lock?
Michael
On Dec 4, 2004, at 8:35 AM, Greg Hudson wrote:
> On Sat, 2004-12-04 at 11:14, Ben Collins-Sussman wrote:
>> * I'm worried that if an admin has post-lock and post-unlock hook
>> scripts, there's going to be 2 useless emails generated whenever
>> somebody even *attempts* to lock an out-of-date wc file.
>
> We can make this case much less common by checking for out-of-dateness,
> grabbing the lock, checking again, and releasing the lock if the second
> test fails.
>
>> I know that the idea of 'svn lock' automatically doing updates was
>> shot
>> down weeks ago, with people screaming about how bad it is to mix
>> subcommand concepts together. But now it seems the only alternative
>> is
>> to make the 'svn lock' command behave a bit schitzo: "lock the
>> file...
>> oh wait, nevermind, unlock it!" Is that behavior the lesser of two
>> evils?
>
> Yes, by a mile.
>
>
> ---------------------------------------------------------------------
> 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
Re: [locking] out-of-dateness checking during lock
Posted by Ben Collins-Sussman <su...@collab.net>.
On Dec 6, 2004, at 12:13 PM, Branko Čibej wrote:
> Peter N. Lundblad wrote:
>
>> This means pushing this check into the FS. I'm not sure everybody will
>> like that:-)
>>
> Since we defined locks to only be valid on the newest revision of a
> file, then obviously the FS _has_ to check that for internal
> consistency.
Let me clarify here: all of the fs locking code *assumes* that a lock
always applies to the latest version of the file. There's no explicit
checking of versions going on anywhere. The command 'lock' means "lock
the latest version of the file", and that's what it has always meant.
It's only the *client* that has any concept of "lock this particular
working file here in front of me."
So I'm going to add this new revnum argument to svn_fs_lock(), but it
will be optional. If it's passed in, then the fs will do a courtesy
check for out-of-dateness, specifically for the benefit of an svn
client. If not passed in, no big deal.
Remember that general DAV clients have no concept of "out of date",
because they don't have working copies. An http LOCK request means
"lock the latest version of the file", so thus DAV clients always do
LOCK, followed by an immediate GET. These clients won't be passing in
the revnum, obviously. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [locking] out-of-dateness checking during lock
Posted by Branko Čibej <br...@xbc.nu>.
Peter N. Lundblad wrote:
>This means pushing this check into the FS. I'm not sure everybody will
>like that:-)
>
Since we defined locks to only be valid on the newest revision of a
file, then obviously the FS _has_ to check that for internal consistency.
> This could be seen as a client asking for a lock on a
>particular revision and the server only allowing locks on the last
>committed revision or later.
>
>
+1. Network roundtrips are bad, race conditions are badder...
But of course, a generic DAV client has no way of even knowing what the
latest revision is. So a DAV LOCK request from, say, MS Office, must
still DTRT.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [locking] out-of-dateness checking during lock
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Sat, 4 Dec 2004, Philip Martin wrote:
> Greg Hudson <gh...@MIT.EDU> writes:
>
> >> I know that the idea of 'svn lock' automatically doing updates was shot
> >> down weeks ago, with people screaming about how bad it is to mix
> >> subcommand concepts together. But now it seems the only alternative is
> >> to make the 'svn lock' command behave a bit schitzo: "lock the file...
> >> oh wait, nevermind, unlock it!" Is that behavior the lesser of two
> >> evils?
> >
> > Yes, by a mile.
>
> Why do we have to accept either option? Why not pass a revision and
> have the fs reject the request if the lock is not HEAD? We could
> make it optional to allow clients to lock HEAD unconditionally if
> wanted.
>
Yes, I'd to do this, too. If you get an error while unlocking,
you will be left with a lock on the server and a WC without the
token. This can be solved by breaking the lock, but I think this a
usability problem. That was what I meant by saying that the operation
wouldn't be atomic. (BTW, you only need to check that the path is at the
last committed revision or later, but that's a detail.)
This means pushing this check into the FS. I'm not sure everybody will
like that:-) This could be seen as a client asking for a lock on a
particular revision and the server only allowing locks on the last
committed revision or later.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [locking] out-of-dateness checking during lock
Posted by Philip Martin <ph...@codematters.co.uk>.
Greg Hudson <gh...@MIT.EDU> writes:
> On Sat, 2004-12-04 at 11:14, Ben Collins-Sussman wrote:
>> * I'm worried that if an admin has post-lock and post-unlock hook
>> scripts, there's going to be 2 useless emails generated whenever
>> somebody even *attempts* to lock an out-of-date wc file.
>
> We can make this case much less common by checking for out-of-dateness,
> grabbing the lock, checking again, and releasing the lock if the second
> test fails.
>
>> I know that the idea of 'svn lock' automatically doing updates was shot
>> down weeks ago, with people screaming about how bad it is to mix
>> subcommand concepts together. But now it seems the only alternative is
>> to make the 'svn lock' command behave a bit schitzo: "lock the file...
>> oh wait, nevermind, unlock it!" Is that behavior the lesser of two
>> evils?
>
> Yes, by a mile.
Why do we have to accept either option? Why not pass a revision and
have the fs reject the request if the lock is not HEAD? We could
make it optional to allow clients to lock HEAD unconditionally if
wanted.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [locking] out-of-dateness checking during lock
Posted by kf...@collab.net.
"Peter N. Lundblad" <pe...@famlundblad.se> writes:
> I am tempted to ask you to forget my previous mail because I have my
> children in my house, so I am kind of "baby sitting", but I don't:-)
Ow :-).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [locking] out-of-dateness checking during lock
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Sat, 4 Dec 2004, Ben Collins-Sussman wrote:
>
> On Dec 4, 2004, at 10:35 AM, Greg Hudson wrote:
>
> > On Sat, 2004-12-04 at 11:14, Ben Collins-Sussman wrote:
> >> * I'm worried that if an admin has post-lock and post-unlock hook
> >> scripts, there's going to be 2 useless emails generated whenever
> >> somebody even *attempts* to lock an out-of-date wc file.
> >
> > We can make this case much less common by checking for out-of-dateness,
> > grabbing the lock, checking again, and releasing the lock if the second
> > test fails.
> >
>
> I'm sold. This means the 'schitzo' behavior of aquiring/releasing the
> lock will only happen in -extremely- rare circumstances.
>
> lundblad: do you agree? If so, I think we've got a good description
> of svn_client_lock(). Go for it.
>
I am tempted to ask you to forget my previous mail because I have my
children in my house, so I am kind of "baby sitting", but I don't:-)
Seriously, I think the atomic behaviour would be ideal, but the above is a
good comprmise. It will require at least three round-trips, but that might
be OK.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [locking] out-of-dateness checking during lock
Posted by Max Bowsher <ma...@ukf.net>.
Ben Collins-Sussman wrote:
> On Dec 4, 2004, at 10:35 AM, Greg Hudson wrote:
>
>> On Sat, 2004-12-04 at 11:14, Ben Collins-Sussman wrote:
>>> * I'm worried that if an admin has post-lock and post-unlock hook
>>> scripts, there's going to be 2 useless emails generated whenever
>>> somebody even *attempts* to lock an out-of-date wc file.
>>
>> We can make this case much less common by checking for out-of-dateness,
>> grabbing the lock, checking again, and releasing the lock if the second
>> test fails.
>>
>
> I'm sold. This means the 'schitzo' behavior of aquiring/releasing the
> lock will only happen in -extremely- rare circumstances.
>
> lundblad: do you agree? If so, I think we've got a good description
> of svn_client_lock(). Go for it.
What about Philip's suggestion?:
| Why do we have to accept either option? Why not pass a revision and
| have the fs reject the request if the lock is not HEAD? We could
| make it optional to allow clients to lock HEAD unconditionally if
| wanted.
IMO, this is more elegant.
Also, won't the test-lock-test approach require multiple network roundtrips?
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [locking] out-of-dateness checking during lock
Posted by Ben Collins-Sussman <su...@collab.net>.
On Dec 4, 2004, at 10:35 AM, Greg Hudson wrote:
> On Sat, 2004-12-04 at 11:14, Ben Collins-Sussman wrote:
>> * I'm worried that if an admin has post-lock and post-unlock hook
>> scripts, there's going to be 2 useless emails generated whenever
>> somebody even *attempts* to lock an out-of-date wc file.
>
> We can make this case much less common by checking for out-of-dateness,
> grabbing the lock, checking again, and releasing the lock if the second
> test fails.
>
I'm sold. This means the 'schitzo' behavior of aquiring/releasing the
lock will only happen in -extremely- rare circumstances.
lundblad: do you agree? If so, I think we've got a good description
of svn_client_lock(). Go for it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [locking] out-of-dateness checking during lock
Posted by Greg Hudson <gh...@MIT.EDU>.
On Sat, 2004-12-04 at 11:14, Ben Collins-Sussman wrote:
> * I'm worried that if an admin has post-lock and post-unlock hook
> scripts, there's going to be 2 useless emails generated whenever
> somebody even *attempts* to lock an out-of-date wc file.
We can make this case much less common by checking for out-of-dateness,
grabbing the lock, checking again, and releasing the lock if the second
test fails.
> I know that the idea of 'svn lock' automatically doing updates was shot
> down weeks ago, with people screaming about how bad it is to mix
> subcommand concepts together. But now it seems the only alternative is
> to make the 'svn lock' command behave a bit schitzo: "lock the file...
> oh wait, nevermind, unlock it!" Is that behavior the lesser of two
> evils?
Yes, by a mile.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [locking] out-of-dateness checking during lock
Posted by Ben Collins-Sussman <su...@collab.net>.
On Dec 4, 2004, at 9:09 AM, Greg Hudson wrote:
> On Sat, 2004-12-04 at 08:28, Peter N. Lundblad wrote:
>> The current RA API lock function doesn't allow the client to provide a
>> revision number. We can ask the server for last committed revision of
>> the
>> path, but that wouldn't atomic. Maybe someone has a plan for how to
>> deal
>> with this. sussman? fitz?
>
> Get the lock.
>
> Then check and make sure you have the most recent version.
>
> If you don't, error out and release the lock.
>
>
Aha, yes, this technique prevents a nasty race condition within the
'svn lock' command.
"I have revision N of the file, is that the latest?" --> "yes."
(in a split-second, somebody commits new version of file)
"Okay, lock the file." --> "locked."
I have two concerns here:
* I'd rather not see every RA->lock() implementation have to
duplicate this logic. Peter, can you put it into svn_client_lock()
instead, so it's shareable?
* I'm worried that if an admin has post-lock and post-unlock hook
scripts, there's going to be 2 useless emails generated whenever
somebody even *attempts* to lock an out-of-date wc file.
I'd like to point out that another solution to this problem is to
- get the lock
- check for out-of-dateness
- if out-of-date, update the file.
I know that the idea of 'svn lock' automatically doing updates was shot
down weeks ago, with people screaming about how bad it is to mix
subcommand concepts together. But now it seems the only alternative is
to make the 'svn lock' command behave a bit schitzo: "lock the file...
oh wait, nevermind, unlock it!" Is that behavior the lesser of two
evils?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [locking] out-of-dateness checking during lock
Posted by Greg Hudson <gh...@MIT.EDU>.
On Sat, 2004-12-04 at 08:28, Peter N. Lundblad wrote:
> The current RA API lock function doesn't allow the client to provide a
> revision number. We can ask the server for last committed revision of the
> path, but that wouldn't atomic. Maybe someone has a plan for how to deal
> with this. sussman? fitz?
Get the lock.
Then check and make sure you have the most recent version.
If you don't, error out and release the lock.
You could put this check into the server, but I'm not sure it's a great
idea. (In particular, I'm not sure how you'd do it over DAV.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org