Здравствуйте, Цыба, Вы писали:
Ц>Здравствуйте!
Ц>Есть удалённый SVN-репозиторий, доступ к администрированию которого полностью запрещён. Сервер удалённого репозитория не обвешан нестандартным функционалом, но также не содержит никаких хуков. Интересует возможность установки некоего локального прокси к удалённому репозиторию (т.е., например, при коммите в него он должен немедленно закоммитать эти изменения в удалённый репозиторий), но к которому можно было бы уже самому привинтить свой набор хуков. Это как бы и обычный прокси, но и как бы "виртуальный" SVN-сервер.
Ц>Возможно ли такое? И если да, то как?
Да, конечно возможно, утилита входит в комплект svn, называется svnsync:
man,
пример настроек. Поднимаете свой "локальный прокси", ставите post-commit hook и пересылаете изменения...
Однако такой подход всё равно связан с рядом ограничений. Например, вы же не один работаете над проектом? Будете организовывать доступ к "промежуточному" для всей команды? Возможно, вместо промежуточных SVN серверов стоит рассмотреть DVCS: git, mercural умеют прозрачно интегрироваться с SVN-ом.
b-3
Здравствуйте, b-3, Вы писали:
b-3>Да, конечно возможно, утилита входит в комплект svn, называется svnsync: man, [url=http://blog.unixstyle.ru/index.php?/archives/88-svnsync-..html
b-3>]пример настроек[/url]. Поднимаете свой "локальный прокси", ставите post-commit hook и пересылаете изменения...
b-3>Однако такой подход всё равно связан с рядом ограничений. Например, вы же не один работаете над проектом? Будете организовывать доступ к "промежуточному" для всей команды? Возможно, вместо промежуточных SVN серверов стоит рассмотреть DVCS: git, mercural умеют прозрачно интегрироваться с SVN-ом.
b-3>b-3
Спасибо большое за ответ!
Да, мне уже намекали на svnsync в качестве команды, вызываемой в обратке коммит-хуков, но я, так подезреваю, я таким образом должен создать копию всего удалённого репозитория (или я не прав?). Плюс, в таком случае я должен указать SVNMasterURI, что, я так понимаю, означает привязку всего slave-сервера к одному master-серверу, независимо от того, какие проекты "хостит" прокси, а также —
куча геморроя с конфигурацией локального прокси с удалённым репозиторием, и то — только в случае, если он настроен соотвествующим образом.
Относительно DCVS дело иначе. Я когда-то пробовал играться с Mercurial с расширением hgsubversion. В принципе, да, то что нужно, с первого взгляда, но и здесь, мне кажется, существует ряд ограничений. Во-первых, команда имеет опыт в Subversion, а переход на идеологически другую систему контроля версий чревата тем, что это может призвести к необратимым последствиям.
(Недавно более-менее постигли философию Subversion
) И, заметьте, просто ради того, чтобы привинтить нужную хук-функциональность к SVN-серверу, администрирование которого запрещено. Т.е., первая проблема идеологического характера. Вторая проблема состоит в том, что я, возможно, не так понимаю DVCS (в частности, Mercurial), и пока совершенно не могу представить, как можно разделить между всеми разработчиками в команде общий набор хуков.
Здравствуйте, Цыба, Вы писали:
Ц>Относительно DCVS дело иначе. Я когда-то пробовал играться с Mercurial с расширением hgsubversion. В принципе, да, то что нужно, с первого взгляда, но и здесь, мне кажется, существует ряд ограничений. Во-первых, команда имеет опыт в Subversion, а переход на идеологически другую систему контроля версий чревата тем, что это может призвести к необратимым последствиям. (Недавно более-менее постигли философию Subversion ) И, заметьте, просто ради того, чтобы привинтить нужную хук-функциональность к SVN-серверу, администрирование которого запрещено. Т.е., первая проблема идеологического характера. Вторая проблема состоит в том, что я, возможно, не так понимаю DVCS (в частности, Mercurial), и пока совершенно не могу представить, как можно разделить между всеми разработчиками в команде общий набор хуков.
Для начала надо понять, что эти хуки должны делать. Проксировать в другой репо это понятно, непонятно правда, что делать при обнаружении конфликтов, если в другой репо кто-то еще накомитил. Но это же не главный сценарий, это ваше решение для какой-то другой проблемы. Озвучьте саму проблему, не надо стесняться.
