On Sep 4, 2008, at 11:21 AM, Markus Kuhn wrote:
> 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".
Well, no output from a post-commit hook is ever sent to a Subversion
client.
> 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.
Book feedback should be sent to the book mailing list. See the
section "Feedback/Contributing" here:
http://svnbook.red-bean.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-09-04 23:13:10 CEST