[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: pre-lock hooks running when repository accessed via web browser

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Mon, 22 Sep 2008 13:56:46 -0400

Mark wrote:
> There was no response to the post below in users list, so I am posting
> to dev list.

Mark, dev@ is not some part of a mythical users@ escalation policy. Would
you contact Frigidaire to find out what flavors of ice cream your local
grocer carried? In the future, please keep Subversion usage questions on
users@. However, since I'm already typing, I'll try to help with your
questions. :-)

> 1) Is there any way to prevent the pre-lock hooks from firing when
> someone opens a word doc in a SVN URL via a standard web browser? (note:
> post-lock never fires in this case)

By code examination, one can see that the only way that post-lock would not
fire on the same action that pre-lock does is if a) the pre-lock hook fails,
or b) the lock acquisition itself fails. Is one of these situations
happening for you?

Also, pre-lock shouldn't be firing at all for a browser-initiated GET
request of a file. So I wonder if, in your situation, the browser is in
fact the fetching agent, or if it is simply handing the WebDAV URL off to
Word, which then does the LOCK/GET/PUT/UNLOCK cycle itself. Are you able to
see by examination of your Apache logs which user agent is responsible for
the interesting bits of this WebDAV exchange?

> 2) Is there any way for the pre-lock hook to know if the hook is being
> fired do to a SVN client requesting a lock versus it being fired because
> a user opening a word doc SVN URL via a web browser?


> This is pre-lock fire from web browser access is causing issues with the
> notification emails we have setup.

Most folks use only the post-lock hook for notification. (What's the value
of sending email every time someone *tried* to lock a file regardless of
whether or not they succeeded?) And what is the value of only sometimes
sending notifications that a file has been locked? Generally, such
notifications exist to prevent users from investing time working on a file
that they ultimately won't be able to commit to (because someone else holds
the lock). I don't see what the client software that took out the lock is
meaningful in this situation, unless perhaps the concern is the sheer number
of locks that Microsoft Word takes out, and the relatively short time it
tends to hold them.

I can only guess that you have some unique purposes and requirements in this
space. Maybe if you explain (to users@, of course) what it is you're trying
to accomplish with your lock-related hooks, someone can help you get from
here to there.

C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on 2008-09-22 19:57:00 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.