Ошибка TortoiseSVN: невозможно подключиться к хранилищу по URL

Я использую TortoiseSVN для подключения к недавно созданному репозиторию на моем сервере RHEL. Я сделал svnadmin create reponameкак root, чтобы создать хранилище. Я просто хочу проверить хранилище с помощью TortoiseSVN, чтобы я мог добавить в него файлы.

Я установил mod_dav_svn и теперь могу подключиться и проверить хранилище. На моем локальном компьютере я добавил файлы в каталог и попытался зафиксировать их. Тем не менее, TortoiseSVN теперь дает

Can't open file '/subversion/langantiques/db/txn-current-lock': Permission
denied

Как мне исправить это?

Если вы создали репо как root (с помощью umask, BTW) и позже попытаетесь получить доступ к репо с действием W как локальный пользователь с протоколом file: /// ( все упомянутые части в предложении важны ), у вас обычная проблема с правами доступа : пользователь, под который вы запускаете svn-процесс, должен иметь достаточные права для работы с репо. Chown или chmod или chgrp repo dir, по мере необходимости (я не шаман, чтобы увидеть вашу FS)

Если ваше репо обслуживается Apache - процесс httpd должен иметь права + r + w на репо

Вам нужно что-то, чтобы обслуживать хранилище для удаленных узлов. Есть три основных варианта;

1. svnserve

   Это простая служба, работающая через порт 3690, которая позволяет получить доступ к вашему хранилищу. Это довольно просто; он может применять настройки разрешений, но не имеет шифрования для сетевого трафика (включая пароли). Вы запустите службу (которая, вероятно, уже установлена ​​на вашем сервере), а затем запустите проверку с svn://URL-адресом.

2. WebDAV

   Для этой опции требуется веб-сервер - возможно, Apache, с модулем mod_dav_svn. Вы можете настроить безопасность (аутентификацию и шифрование) на веб-сервере, а также контроль доступа; это, вероятно, самый гибкий из вариантов по этой причине. Вы можете использовать http://или https://URL, чтобы проверить это.

3. SSH

   Эта опция использует настройку SSH, которую вы, вероятно, уже настроили; таким образом он получает хорошую аутентификацию и шифрование. Но, поскольку он использует пользователей Linux, вам нужно будет перепрыгнуть через несколько обручей, чтобы заблокировать любого пользователя, которому вы хотите иметь доступ к SVN, но не доступ к оболочке. Это также требует некоторого спора, чтобы заставить работать SSH-соединение - в прошлый раз, когда я облажался с этим, он включал подачу черепахи plink.exeфайла из PuTTY . Вы получите доступ к этому с помощью svn+ssh://URL.

Пара вопросов здесь - есть некоторые довольно сложные операции с ключами сертификатов / PVT, которые, хотя и вполне приемлемы для plink / pageant, могут оказаться бесполезными. SVN на сервере может быть абсолютно нормальным и жизнеспособным, но соединение TortoiseSVN прекрасно работает.

Теоретически, если конфигурация puTTY ssh работает, вы должны иметь возможность подключиться через включение 'load' в командной строке TortoisePlink, которую вы перетаскиваете в запись Настройки-> Сеть-> SSH Shell. Обратите внимание на слово «должен».

Я пробовал каждый шаг в каждой рекламе HowTo / FAQ / TortoiseSVN (за исключением тех, которые требуют привилегий root на сервере, чтобы вмешаться в параметры / etc / svnserver), и пока что абсолютно ничего не работает. Конечным результатом около двух с половиной недель усилий является сообщение «Невозможно подключиться к хранилищу по URL-адресу ...». Тем не менее, среда SVN работает как сон, работает отлично и замазка, а корневой путь SVN я извлек непосредственно из информационной строки svn (за исключением постороннего префикса file: ///).

Я убежден, что что-то не так, что настолько очевидно, что никто не думал упомянуть об этом в литературе.