pre-lock hooks running when repository accessed via web browser

[Mark <em...@gmail.com>]

Hi,

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

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)

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.

Thanks,

Mark

---------- Forwarded message ----------
From: Mark <em...@gmail.com>
Date: Mon, Jun 30, 2008 at 2:46 PM
Subject: pre-lock hooks running when repository accessed via web browser
To: users@subversion.tigris.org



We have pre-lock and post-lock hooks setup. The pre-lock hook denies users
access to create locks certain areas of the repository. Users can't commit
in those areas via the pre-commit hook (even though they have write access
via the authz file) so we though it best to prevent them for locking and
editing there as well.

What we have found is that when users access these restricted areas in the
repository with a web browser via a direct svn URL to a specific file, the
pre-lock hooks are run. When this occurs, the hooks send out a email to
notify that the pre-lock hook failed because the user is not allowed to lock
those areas of the repo. The user is able to view/save the file via the web
browser.

- apache 2.2.8
- openssl 0.9.8h
- svn 1.4.6

Any reason why accessing a file in a subversion repo via a web browser is
causing the pre-lock hooks to run?

Are there any other hooks that are run when a subversion repo is accesses in
this way?

Thanks

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

["C. Michael Pilato" <cm...@collab.net>]

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?

Nope.

> 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 <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

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

["C. Michael Pilato" <cm...@collab.net>]

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?

Nope.

> 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 <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand