Отказано в разрешении SVN - txn-current-lock

Папка репозитория в файловой системе должна принадлежать или, наконец, иметь разрешение на чтение/запись того же пользователя Linux, над которым работает ваш svn или apache через web-dav...

В моем случае это было:

$ chown -R www-data:www-data /svn/reponame

Но в каком-то другом случае это может быть по-другому, например

$ chown -R someuser:somegroup /svn/reponame

Поэтому замените someuser:somegroup правильными значениями.

Вы должны добавить бит SETUID для папки /var/www-svn/, потому что в транзакциях будут папки, созданные во время запуска SVN для сохранения транзакций, которые представлены папками.

Это означает, вкратце, просто сделать

chmod +s -R /var/www-svn/

должен решить проблему.

Демон svnserve работал под моим пользователем, а не как root. Я убил процессы svnserve, работающие под моим пользователем, и перезапустил их как root. Теперь это работает.

Моя проблема заключалась в том, что я применил разрешения, а затем сделал svnadmin create, поэтому снова потребовалось установить разрешение.

 $ sudo chown -R www-data:subversion myproject
 $ sudo chmod -R g+rws myproject

Кажется, вопрос для superuser.com. На первый взгляд, у группы svn нет прав на запись в эту папку. Так что, возможно, это проблема.

Ссылка больше не работает, см. комментарии для быстрого решения Взгляните на это http://www.svnforum.org/threads/35493-Can-t-open-db-txn-current-lock-permission-denied

Если у вас нет прав sudo:

В моем конкретном случае я мигрировал с одного общего сервера Webfaction на другой. Копирование файлов должно было назначить право собственности на весь репозиторий моему имени пользователя, в то время как владельцем, вероятно, должен быть apache, чтобы репо было доступно. Я не мог применить chown apache:mygroup repo, потому что у меня нет доступа к пользовательскому apache. Без root-доступа единственным способом заставить его работать было chmod -R 777 . внутри корня моего репозитория, в конечном итоге удалив файл блокировки, на который у меня не было прав доступа. Это, наконец, решило проблему, и я мог снова зафиксировать.

Разрешение на чтение и запись отсутствует для созданного репо.

chcon -R -t httpd_sys_rw_content_t /path_to_svn Пример: chcon -R -t httpd_sys_rw_content_t /opt/svn/trunk

И последнее, но не менее важное: если ваш репозиторий принадлежит пользователю и группе svn

(sudo chown -R svn:svn /var/svn/repos)

Обязательно добавьте пользователей, которые могут получить к нему доступ, в группу svn. vi /etc/group

svn:x:502:user1,user2

Хотя вопрос очень старый, он занимает более высокое место в Google, но один с подрывной деятельностью на Apache / httpd в Linux не находит решения полезными.

Я запускаю подрывную деятельность на Apache, CentOS Linux. Для меня проблема была связана с SELinux, и отключение помогло мне.

Перед этим необходимо соблюдать осторожность, так как на рабочем сервере не рекомендуется отключать SELinux. Пожалуйста, внимательно прочитайте документацию, прежде чем пытаться это сделать.

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Enabling_and_Disabling_SELinux-Disabling_SELinux.html

Как предложил Стюарт в комментарии, другое решение — обновить права доступа к файлам, хотя более подробная информация недоступна, некоторые настройки прав доступа к файлам должны помочь.

Перезапустите Eclipse IDE.

У меня был точно такой же случай, и я потерпел неудачу при попытке зафиксировать изменения с помощью EclipseIDE.

Во время работы Eclipse я изменил группы пользователей, которым нравится фиксировать в репозитории.

Удивительно, но я заметил, что как только я перезапустил Eclipse, измененная группа/права репозитория были предоставлены. Я думаю, что Eclipse держит ssh-канал открытым, и во время сеанса ssh-канала измененные групповые права игнорируются.

Во время eclipse-restart сеанс ssh воссоздается, а измененные групповые права прикрепляются к новому сеансу ssh, предоставляющему фиксацию.