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

Right, you need a way to propagate locks that preserves ownership. 'svn
lock' can't do that unless you authenticate as the desired user. And if
you've got your synchronization path protected by authn credentials alone,
you're out of luck on that approach.

Is there some way that you could, instead of using authn credentials to
protect your slave repository, instead protect it based on the IP address of
the master server? That way you could allow lock operations as the proper
connecting username, but without opening up the slave repository to
accidental commits by your real users?

Mike Coyne wrote:
> Ok ,I think I understand a bit more now, So my core problem is that
> owner of the lock on the master is user who set it, but the owner of the
> lock on the slave is "repository owner" which has the only write
> privileges. When svnsync sync runs... The commit is sent to the slave ,
> the slave process the commit but sees the slave lock owner != commit 's
> proxied owner?
>
> If this is what is going on, how can
> A) reset the ownership of the lock on the slave or
> B)convince svnsync to overwrite the lock as the proxied owner?
>
> My current post-lock script on the master is setting the locks on the
> slave along this line running
> ...
> echo "Lock set on master by $USER" >$TMPFILE
> svnlook lock $REPOS $p2 | grep -v UUID | grep -v Owner: | grep -v
> Created: | grep -v Expires: | grep -v Comment >> $TMPFILE"
> svn lock --force --username analysis --password xxxxx
> "https://$SLAVE/svn-proxy-sync/Source$p2" -F $TMPFILE
> ...
>
> -----Original Message-----
> From: C. Michael Pilato [mailto:cmpilato_at_collab.net]
> Sent: Wednesday, March 04, 2009 8:48 AM
> To: Mike Coyne
> Cc: dev_at_subversion.tigris.org; John Allan (PTC); Michael Taylor
> Subject: 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=1267302