svn: could not connect to server

Сегодня столкнулся с интересной ошибкой при попытке экспорта проекта из репозитория :

[-]
View Code Text
$ svn export -q -r8913 https://my.repository.com/svn/trunk /var/www/some/path
svn: OPTIONS of 'https://my.repository.com/svn/trunk': could not connect to server (https://my.repository.com)

Произошло это после обновления системы (на машине стоит ).

Первое подозрение — что-то не то с DNS, ибо извне к репозиторию есть доступ. Проверил:

[-]
View Code Text
$ wget https://my.repository.com
--2009-07-07 13:10:21--  https://my.repository.com
Resolving my.repository.com... 12.34.56.78
Connecting to my.repository.com|12.34.56.78|:443... connected.
HTTP request sent, awaiting response... 200 OK

Получается, что проблема где-то в subversion, а не в невозможности соединения с сервером или криво настроенном DNS.
Далее »

Автор: , опубликовано в: Linux, комментариев: 15
7
Июл
2009

Subversion, ionCube и прозрачное шифрование

В данный момент я работаю над очень интересным проектом ExtremeMember (который, кстати, работает на WordPress). Одной из особенностей разработки является то, что мы используем (также известный как ) для обновления кода на всех сайтах (будь то основной, тестовый или клиентский — которых больше сотни — сайт).

Другой особенностью разработки является то, что мы предоставляем клиентам FTP-доступ ко всему сайту (разумеется, каждый клиент имеет доступ только к своему сайту — целиком — а не только к каталогу uploads). Логично, что для предотвращения "кражи интеллектуальной собственности" мы шифруем все наши файлы (в целях безопасности мы также ограничиваем доступ к некоторым другим файлам — например, базовые файлы WordPress доступны только для чтения, но это другая история). Для шифрования мы используем Encoder.

Задача такова: при изменении ветки с кодом клиентских сайтов её нужно автоматически зашифровывать. Проблема в том, что мы (разработчики) работаем над открытым кодом, а клиенты должны получить закрытый (шифрованый) код; как следствие, одну и ту же ветки в репозитории мы использовать не можем. Далее »

Автор: , опубликовано в: Linux, комментариев: 11
3
Авг
2008