C. Michael Pilato wrote:
> Oh, man, I can't believe I didn't think of this early. *thump*
>
> I don't think svnsync transmits lock tokens at all. This means that the
> svnsync process will always be denied the right to change locked files.
>
Yah, that could be a ... problem.
> I must admit that I'm not sure how to proceed.
>
> Subversion Devs (if any are following this thread): Got any ideas?
>
So a workaround does come to mind ... not a nice one.
Since the slave repo is read-only, there's no real harm done if the
synchronization script plays a bit loosely with the locks. I'd suggest
(as a workaround only) that the sync script checks for locked objects in
the changeset, unlocks 'em on the slave, does the svnsync, and locks
them again. Could be a bit of a race there if the unlock hook gets
called before the sync is done, as it probably will; nothing
insurmountable though.
An even easier workaround is to not transmit the locks to the slaves at
all, but that's a bit extreme.
Of course the only real fix is for svnsync to transmit lock tokens, too.
Dunno how easy or safe that would be.
-- Brane
> Mike Coyne wrote:
>
>> I corrected my configuration as suggested. Such that locks created on
>> the master now have the same owner as those on the slave. I also backed
>> out some prior work so that the sequence of operations is no longer
>> altered . But for some reason the svnsync command still fails? Below it
>> the rough sequence
>> First locked the file in the repo...
>>
>> 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 $USER --password $USER
>> "https://$SLAVE/svn-proxy-sync/Source$p2" -F $TMPFILE
>>
>> returned
>> 'post-commit' locked by user 'mcoyne_at_PBDENTON.PACCAR.COM'.
>>
>> Then commited the change.
>> svnsync sync --username analysis --password analysis
>> https://$SLAVE/svn-proxy-sync/$REPODIR
>> which returned in error
>> Transmitting file data .svnsync: Server sent unexpected return value
>> (423 Locked) in response to PUT request for
>> '/svn-proxy-sync/Source/!svn/wrk/323d934e-6390-4459-80e1-538f0804332d/tr
>> unk/adminstration/svn/master/svn/Source/hooks/post-commit'
>>
>> Which was followed up by the unlock
>> svn unlock --force --username $USER --password $USER
>> "https://$SLAVE/svn-proxy-sync/Source$p2"
>> returned
>> 'post-commit' unlocked.
>>
>> I did a svnadmin lslocks on the slave which returned withno locks
>> So I relocked the file to compare the output of the lock data?
>> From the slave
>> [analysis_at_nike hooks]$ svnadmin lslocks /var/www/svn/Source
>> Path: /trunk/adminstration/svn/master/svn/Source/hooks/post-commit
>> UUID Token: opaquelocktoken:1ad25194-d51b-419c-beac-adae73d6b910
>> Owner: mcoyne_at_PBDENTON.PACCAR.COM
>> Created: 2009-03-04 12:36:49 -0800 (Wed, 04 Mar 2009)
>> Expires:
>> Comment (3 lines):
>> Lock set on master by mcoyne_at_PBDENTON.PACCAR.COM
>> <ns0:owner>lock prior to edit</ns0:owner>
>>
>> And on the master
>> mcoyne_at_styx.pbdenton.paccar.com:/var/www/svn/Source # svnadmin lslocks
>> `pwd`
>> Path: /trunk/adminstration/svn/master/svn/Source/hooks/post-commit
>> UUID Token: opaquelocktoken:928723fb-b768-44e3-82c3-b50efc4ea4c8
>> Owner: mcoyne_at_PBDENTON.PACCAR.COM
>> Created: 2009-03-04 14:36:47 -0600 (Wed, 04 Mar 2009)
>> Expires:
>> Comment (1 line):
>> <ns0:owner xmlns:ns0="DAV:">lock prior to edit</ns0:owner>
>>
>> The comments differ slightly but the owners are the same?
>>
>> Any thoughts?
>>
>> -----Original Message-----
>> From: C. Michael Pilato [mailto:cmpilato_at_collab.net]
>> Sent: Wednesday, March 04, 2009 12:03 PM
>> To: Mike Coyne
>> Cc: Subversion Developers
>> Subject: Re: post-commit hook fires before post-lock hook
>>
>> [Please keep discussions of this sort on-list for the benefit of
>> others.]
>>
>> Mike Coyne wrote:
>>
>>> My current configuration I has two "locations" the master user goes
>>> through svn-proxy-sync and regular users through /repos. How would I
>>> adjust the auth to get what you described? I have not setup apache
>>>
>> like
>>
>>> that before? I am not sure how to the get/pass the username.
>>>
>> [Potentially sensitive information stripped.]
>>
>> I'm not precisely sure what you need. At a minimum, I think that your
>> <Location /svn-proxy-sync> block needs something like the following,
>> where
>> W.X.Y.Z is the IP address of your master server:
>>
>> Order deny,allow
>> Deny from all
>> Allow from W.X.Y.Z
>>
>> But you're using Kerberos auth for your real users, and Basic auth for
>> your
>> sync stuff. So, maybe the trick is to keep usernames for all your users
>> in
>> your slave server's Basic auth password file (and keep that list of
>> usernames in sync with your Kerberos configuration somehow ...
>> handwaving
>> here ...), except define the passwords for all those users to be the
>> same
>> private password (or maybe at least something calculable by the master
>> server based on username). That way, in the master server's hooks, you
>> can use:
>>
>> svn lock SOME_URL --username USERNAME --password PRIVATE_PASSWORD
>>
>> where USERNAME is the username provided to the hook, and
>> PRIVATE_PASSWORD is
>> the password you've setup as the password assigned to all the users in
>> the
>> slave's /etc/httpd/conf/password. This should allow
>> authenticated-as-real-usernames changes on the slave from the master,
>> without exposing the slave's repository to change from anywhere except
>> the
>> master server.
>>
>> Does that make sense? (Sorry, I can't help much more on this due to
>> ignorance of Kerberos auth.)
>>
>>
>
>
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1272718
Received on 2009-03-05 17:09:51 CET