Re: svn commit still holds locks when server-side post-commit runs

John Peacock wrote on 2008-09-04 15:32 UTC:
> Markus Kuhn wrote:
> > I am using svn 1.4.4 (SUSE Linux 10.3) with a server-side post-commit
> > hook script that (under some circumstances) calls an svn update in the
> > same working directory in which I executed the svn commit. In that case,
> > I get an error message from the svn update, complaining that it cannot
> > acquire locks on the working directory.
>
> Yeah, don't do that. ;-)
>
> You can fork the update (and sleep a second or two) to allow the client
> to finish, but it is really a Very Bad Idea(TM) to have server-side
> updates firing into the same WC as the commit came from. That usually
> means your workflow process is sub-optimal.

In case you are interested in the reasons behind this choice, here a few
more details of our setup:

We use Subversion to give users version-controlled write access to a web
site. The web server serves HTML files from a directory that is a normal
svn working directory. Users check out their own working copy, and when
they commit their changes, we use a post-commit script to run "svn
update" on the web server's working directory, such that the commited
changes become visible to the world wide web. This has worked extremely
well for almost two years now.

There has been only one minor snag. Occassionally, a webmaster wants to
edit files in the web server's working directory itself directly. This
is mostly for debugging of cgi scripts, which can only be tested easily
from within the web server's working directory, and where it is too
cumbersome to commit each single test edit just to get access to the web
server's working directory from elsewhere. If the webmaster then commits
her changes from the web server's working directory, she gets an error
message from the post-commit script that the svn update can't acquire
the locks. It does not actually cause any problems, because the file is
already up-to-date, and she could easily to the update herself, but it
leads to an unpleasant error message. That's all.

There is also a good reason for why we don't fork of the "svn update" in
post-commit and execute it with a delay. In our svn-based content
management system ("Ucampas"), users edit bare-bones "index-b.html"
files, which (after the "svn update") a script converts into the highly
decorated index.html files that the user sees. This HTML decoration
script could output error messages that we want the user to see in their
post-commit error output. Therefore, it has to be called after the svn
update, but can't be forked as we still want to see its stderr at the
end of "svn commit".

> > Shouldn't "svn commit" have released all its locks on the working
> > directory by the time the post-commit script is executed on the server?
>
> No, because commit isn't complete until the server returns from the
> post-commit hook. QED

A classicist might argue that the name of the hook creates slightly
different expectations:

  "post-": Latin prefix, meaning *after*

I'm not strongly arguing that execution of the commit and execution of
the post-commit hook should be two entirely seperate transaction
initiated by the "svn commit" process. Mostly because this would open a
new can of security worms, where the "svn commit" process could delay
(or even prevent?) maliciously the execution of the post-commit hook if
that gets only started after "svn commit" has confirmed the release of
its locks.

But perhaps

  http://svnbook.red-bean.com/nightly/en/svn.ref.reposhooks.post-commit.html

could go into a bit more detail of what actually happens, adding
something like:

  The post-commit hook has to complete before the result of the
  transaction is reported back to the "svn commit" client. As a result,
  the client will not release any locks it holds on the working directory
  before the post-commit hook has finished.

Markus

-- 
Markus Kuhn, Computer Laboratory, University of Cambridge
http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org