On Mon, Sep 22, 2008 at 1:56 PM, C. Michael Pilato <cmpilato_at_collab.net>wrote:
> Mark wrote:
>
> > 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?
Yes.
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?
>
Yes. I was unaware of the Microsoft user agent sending LOCK.
I am no sure this is a good thing. To have non-SVN applications have the
ability to influence Subversion's internal repository processing as if it
was a SVN client.
If Word cannot commit to the respository even when given a lock, whats the
point of giving a lock to Word? If Word can still get the file when denied a
lock, whats the point of denying Word the lock? Given the previous to
points, why is Subversion firing off internal repository lock hooks for Word
(or any other non-SVN client that can speak WebDav)?
> > 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.
Actually, there is. Its not pretty but it works. See below.
>
> > 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.
We have some Subversion repositories used for documentation (non-mergeable
file) and as such we deny lock steals and have implemented a notification
setup:
- pre-lock hook:
- checks for current lock owner, and if found:
- set rev property for file on current revision with user who
attempted to get lock
- send advisory email to lock holder, letting them know someone would
like to edit the file
- deny lock with exit non-zero (preventing any "steal lock" requests)
- post-commit hook:
- move any pre-lock rev properties for files from prev to current
revision property
- post-unlock hook:
- checks for pre-lock hook set properties and notifies interested
parties (those that tryed to get the lock eariler) by email of the released
file lock.
- clears revision pre-lock property for the files after email is sent.
We also have a tag section of the SVN repos. No one is permitted to edit
there. To prevent people from locking and working one documents only to fine
out that they can't commit later, we have denied locking in those locations
of the repo though the pre-lock trigger. We have notification emails set out
for this scenario as well.
So as one may see, the problem is that the pre-lock hook fires when someone
opens a document from a web page and the non-SVN app opening the document
sends a WebDav LOCK method. Since Subverison itself has no way to know if
the lock request is serious (from a SVN client) it fires hooks for any
WebDav LOCK method received. This was causing havoc on the email
notification system.
The "workaround", if one is using apache for the subversion server, is to
compile in forensic logging. Then have the pre-lock hook parse the forensic
log for the matching (url path) log line for transactions that have not
completed (log lines without a corresponding second log line for the
transation). This is really ugly, but works. No false emails will be sent
anymore in either case. All nonSVN user agents are now denied all lock
requests and no emails sent nor rev properties set for nonSVN user agents.
Mark
> --
> C. Michael Pilato <cmpilato_at_collab.net>
> CollabNet <> www.collab.net <> Distributed Development On Demand
>
>
Received on 2008-10-05 18:19:25 CEST