Мне удалось настроить сервер SVN (через SSL) и клиент TortoiseSVN на Win.
Я сделал крючок после фиксации для тестового проекта. Post-Commit обновит веб-каталог, чтобы приложение на PHP можно было запустить с новейшей версией.
Все работает, когда делается поверх оболочки. Единственная проблема в том, что когда я фиксирую изменения на клиенте в Win, изменение фиксируется, но HOOK выдает ошибку
post-commit hook failed (exit code 1) with output:
Error validating server certificate for 'https://SERVER_IP:443':
- The certificate is not issued by a trusted authority. Use the
fingerprint to validate the certificate manually!
- The certificate hostname does not match.
Certificate information:
- Hostname: DEVSRVR
- Valid: from Fri, 28 Jan 2011 09:22:45 GMT until Sat, 28 Jan 2012 09:22:45 GMT
- Issuer: PHP, SS, SS, SRB
- Fingerprint: 5f:d0:50:d6:dd:a6:d4:64:a5:ac:3a:4b:7c:7d:33:e3:75:dd:23:9f
(R)eject, accept (t)emporarily or accept (p)ermanently? svn: OPTIONS of 'https://SERVER_IP/svn/myproject/trunk': Server certificate verification failed: certificate issued for a different hostname, issuer is not trusted (https://SERVER_IP)
Это поведение SVN по умолчанию при работе с сертификатом, которому он не доверяет. Взгляните на раздел управления сертификатами SSL в "Контроль версий с помощью Subversion".
Если клиент получает сертификат сервера, ему необходимо убедиться, что он доверяет сертификату: действительно ли сервер является тем, кем он себя называет? Библиотека OpenSSL делает это путем проверки лица, подписавшего сертификат сервера, или центра сертификации (CA). Если OpenSSL не может автоматически доверять ЦС или возникает какая-либо другая проблема (например, истек срок действия сертификата или несоответствие имени хоста), клиент командной строки Subversion спросит вас, хотите ли вы в любом случае доверять сертификату сервера.
Этот диалог должен показаться знакомым; По сути, это тот же вопрос, который вы, вероятно, видели в своем веб-браузере (который является просто еще одним HTTP-клиентом, таким как Subversion). Если вы выберете вариант (p) постоянный, сертификат сервера будет кэшироваться в вашей частной области авторизации / области выполнения точно так же, как кэшируются ваше имя пользователя и пароль (см. Раздел «Кэширование учетных данных клиента»). В случае кэширования Subversion будет автоматически доверять этому сертификату в будущих переговорах.
Похоже, решение состоит в том, чтобы просто запустить его вручную и навсегда принять сертификат или установить ssl-trust-default-ca значение true в вашей конфигурации.
Многие установки OpenSSL также имеют заранее определенный набор центров сертификации по умолчанию, которым почти все доверяют. Чтобы клиент Subversion автоматически доверял этим стандартным полномочиям, установите для переменной ssl-trust-default-ca значение true.
Как сказал @ runlevel6, вы должны принять сертификат с тем же пользователем, который запускает ловушку.
Если по какой-то причине у вас есть разрешение на редактирование ловушки, но не на выполнение команд, поскольку этот пользователь, попробуйте временно изменить команду svn в ловушке на это:
echo "p" | svn command_that_shows_the_error
Если у вас нет явной команды svn в хуке, используйте это:
echo "p" | svn info http://repositoryurl
Затем запустите его один раз, чтобы он принял сертификат навсегда. Мне пришлось сделать это один раз из-за задания cron, которое удалило кеш аутентификации, и это сработало.