Re: post-commit hook fires before post-lock hook

Mike Coyne wrote:
> I am currently working with a mirrored svn server -master configuration
> with using subversion-1.5.5. On linux rhel5.3 .
>
> I have noticed a issue when a commits contains a locked file correctly
> owned by the user making the commit.
>
> The master correctly automagicly unlocks the file for the user and
> process the commit but the post-commit hook and post-lock hook are
> reversed . This is a problem if the post-commit in my case runs the
> svnsync sync https://slave/... and the post-lock run the svn unlock
> https://slave/...

Let me interrupt here to make sure I understand you. You've got a user who
has a locked file, has changes to that file, and is committing those
changes. The changes are getting committed to the repository correctly, but
you were expected to see the post-...unlock (?) hook run before the
post-commit one does. (You typed "post-lock", but I don't see anything in
the above description that describes something being locked that previously
wasn't.)

There are some phrasings in your paragraph that make me think you might be
misunderstanding what Subversion does when committing locked files. You say
the master "automagicly unlocks the file" -- but that's not actually what
happens at all. The file remains locked by the user for the duration of the
commit. "Locked" doesn't mean "read-only". "Locked" means "reserved for
editing only by a particular user". So, in the core stages of a commit
scenario involving a locked file (where the committing user owns the lock,
of course), you should not expect to see any locking or unlocking happening,
and therefore no post-lock or post-unlock hooks.

But the Subversion client, by default, doesn't stop with the core commit
scenario. Unless you specify --no-unlock when committing (or unless your
runtime configuration area has "no-unlock" set), the client will follow up a
successful commit with an unlock operation. "Commit went well, my work is
done here, I don't need the lock any more." That kinda thing.

This is why the ordering of hooks for a commit with locks looks like so:

   start-commit
       ### transmit commit data
   pre-commit
       ### upgrade commit transaction to a new revision
   post-commit
       ### commit comes back to the client successful
   pre-unlock
       ### unlock any locked files
   post-unlock

> The locks were placed on the slave with a post-lock hook to snv lock
> under the owner of the "slave repository" which is the only user with
> write privileges on the slave. I was not able to find a way lock the
> file as the repository owner ( same user running svnscyn ) and set the
> ownership of the lock to a different user?
>
>
> the svncsync fails due to a locked file on the slave. I was able to
> reverse the order by submitting torque batch jobs from the post hook
> scripts and putting the commit batch job in a holding patterns until the
> queue for the unlocks was clear . This is very unwieldy to manage.
>
> I have not yet found where to look in the code for a place to start
> digging. Any help would be appreciated or any suggestions as to a more
> elegant work around for un-reversing the post hooks...
>
> Thank You in advance for your time..
>
> Mike Coyne
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1266766

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1267132