On Jul 7, 2005, at 4:34 PM, Philip Martin wrote:
>
>
> I don't suppose it matters a great deal if the error gets returned by
> svn_fs_lock instead of svn_repos_fs_lock, but the fact that the race
> exists means that the code is suspicious. It's a bit like libsvn_wc
> doing stat() to check a file exists before open() rather than simply
> handling the open() error.
>
I had a similar discussion with kfogel today. I pointed out that in
the case of a commit, the commit-transaction may have been built
successfully with no just-in-time conflicts, and then 'pre-commit'
runs... but there's still a race, right? 'pre-commit' runs, and yet
there's still no promise that svn_fs_commit() will succeed. So this
doesn't seem any more suspicious to me: a bit of just-in-time
checking from libsvn_repos, doing the best it can.
Karl feels that if we don't add this change, we should probably
rename 'pre-lock' to 'start-lock', that there's a subtle difference
between those things. 'start-foo' means "you're making an attempt to
do foo", whereas 'pre-foo' means "you've attempted foo, and it's just
about to happen now".
In any case, the motivation here was that on the users@ list,
somebody was trying to write a hook that notified someone, "hey, this
user stole your lock". It turns out that it's impossible to do right
now. 'post-lock' doesn't know who the original lock-owner was -- the
original lock is long gone. 'pre-lock' works, but it turns out the
user was getting two emails: first, when the stealer ran 'svn
lock' (and failed), and again when the stealer successfully retried
with '--force'.
Thoughts?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 8 02:59:01 2005