Jani Averbach wrote:
> On 2005-07-05 15:06-0500, Ben Collins-Sussman wrote:
>> Bruce, did you ever figure this problem out?
>>
> In fact I saw this behaviour just two days ago in RHEL4
> with SVN 1.1.1.
>
>>
>> On Apr 28, 2005, at 11:32 AM, Bruce Christensen wrote:
>>
>>> We're running svn client 1.1.4 on Fedora Core 3, accessing a server
>>> running svn 1.1.1 on RH Enterprise Linux AS release 4 using the
>>> svn+ssh protocol.
>
> This system runs via ra_dav.
>
>>> Whenever one of our users does a commit, svnrep/db/write-lock is
>>> created, which is to expected, However, the lock is never removed when
>>> the commit is finished, which means that no other users can commit
>>> until someone manually removes the write-lock file from the
>>> repository.
>
> Same here.
>
>>> File permissions immediately after user brucec does a commit are as
>>> follows:
>>> [brucec@admin Raid]$ ls -l /Raid/svnrep/db
>>> -rw-r--r-- 1 brucec serveradmin 0 Apr 28 10:27 write-lock
>
> Same again.
>
>>> At this point, brucec can continue to commit, but any other user who
>>> tries to commit gets the following message:
>>>
>>> Transmitting file data .svn: Commit failed (details follow):
>>> svn: Can't open file '/Raid/svnrep/db/write-lock': Permission denied
>>> svn: Your commit message was left in a temporary file:
>>> svn: '/tmp/issues/svn-commit.tmp'
>>>
>
> And again.
This is just the classic permissions problem that we've seen many many times
before.
chmod g+w /Raid/svnrep/db/write-lock
The presence of the file write-lock does _not_ indicate a claimed write
lock. It exists all the time.
libsvn_fs_fs takes out an apr_file_lock()-type lock to acquire write access
to the repository.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jul 6 01:12:39 2005