Я работаю в среде, которая использует сервер Subversion в центральном месте, который должен передавать свое содержимое в 4 различных среды (prod, test и т. Д.). В этих средах нам вообще не нужны функции Subversion, просто для того, чтобы иметь возможность получить доступ к содержимому всех / тегов /, хранящихся в репо, с помощью http и локальной файловой системы.
Для этого у нас есть два возможных подхода:
1) зеркала Subversion во всех средах, обновляемые с помощью svnsync, а затем доступные в каждом месте через svn -> web_dav_svn -> davfs (доступ к FS здесь) -> apache (доступ HTTP здесь)
2) svn-экспорт / тегов в центральном месте, а затем rsyncing файлов в другие места, возможно, после жесткой привязки ранее экспортированной файловой структуры.
Хотя вариант 1 во многих отношениях кажется «изящным» (хотя прохождение через apache дважды ???), он снижает значительный риск в сторону активной рабочей среды, а не удерживает ее в центральном месте, которое, по сути, является «автономным», поскольку поскольку он никогда не использовался в работе этих сред. Я также был бы обеспокоен тем, что так глубоко в проект будет помещен в значительной степени одноразовый и игнорируемый проект плавких предохранителей, например davfs. Rsync скучен и стабилен, и, поскольку все, что нам нужно, это доступ к файлам на наших условиях, мы можем получить его с помощью действительно простого и надежного набора инструментов.
Любые мысли действительно приветствуются.
Перехватчик post-commit может работать, но это приводит к возможному повреждению, если в середине rsync есть активность записи. Также были бы эффективны локальные обновления, но они не гарантируют безупречную сборку из каждого тега, поскольку могут быть внесены локальные изменения.
Вы можете рассмотреть коммерческий продукт, такой как Subversion MultiSite который будет хранить точную копию репозиториев в каждом месте. Эти локальные реплики обновляются автоматически по мере внесения изменений и обеспечивают производительность локальной сети на каждом узле.
1) зеркала Subversion во всех средах, обновляемые с помощью svnsync, а затем доступные в каждом месте через svn -> web_dav_svn -> davfs (доступ к FS здесь) -> apache (доступ HTTP здесь)
Вам не нужно запускать apache, чтобы иметь доступ к репозиторию svn, особенно когда доступ к нему будет иметь только один пользователь. Доступ к репозиторию можно получить file:// протокол, если он хранится на локальном диске.
Ваши инстинкты верны. Вариант 1, кажется, привносит много сложностей при относительно небольшом выигрыше.
Вариант 2 будет легко реализовать с помощью post-commit перехватчик, который обновляет рабочую копию репозитория, а затем использует rsync для перемещения репозитория в необходимые места назначения. Обновление локальной рабочей копии вместо использования svn export - будет намного эффективнее, если ваш репозиторий большой.
Использование svnsync может быть сложным, но после настройки вам редко придется иметь дело с ним. Единственная проблема, с которой я столкнулся при использовании svnsync в нескольких местах, - это случайная блокировка svnsync, которая не снимается, которую можно быстро исправить, а затем все снова быстро обновляется. Я бы сделал это примерно один или два раза в год с тремя синхронизированными серверами центрального сервера.
Другое преимущество svnsync: если вам нужен другой код, он там. Вам не нужно проходить еще один процесс настройки, чтобы получить дополнительный контент.
И последняя, но, вероятно, лучшая причина для нескольких локаций svnsync, готовых к отказу, если ваш центральный репозиторий окажется трудным и невосстановимым.