У меня возникла ситуация, в которой я пытаюсь решить проблему с использованием SVN-сервера моей компании. Мы храним весь наш важный код на заблокированном сервере (назовем его сервером «dev»). Есть некоторые файлы, которые должны редактироваться пользователями за пределами корпоративной сети, поэтому у нас есть другой SVN-сервер («глобальный» сервер), доступный за пределами брандмауэра и содержащий копии тех каталогов, которые содержат файлы, необходимые извне. Если это имеет значение, структура папок глобального сервера является подмножеством сервера dev (то есть это всего лишь несколько файлов / каталогов выбора, но все они имеют одинаковые относительные пути и т. Д.). Я включил краткое объяснение , почему мы пытаемся сделать это в конце поста, если вы хотите прочитать его, но, поверьте мне, это должно быть сделано на двух отдельных серверах.
На первый взгляд, svnsync кажется идеальным для этой работы, но есть неприятная проблема, требующая, чтобы это было единственное, что изменяет целевой репозиторий. Очевидно, что это не сработает, поскольку наш репозиторий dev интенсивно используется.
Мне кажется, что есть два решения, и ни одно из них не является хорошим решением. Я надеюсь, что кто-то может помочь мне настроить один из них или, что еще лучше, предоставить альтернативу.
- Моя первая идея - использовать внешние компоненты на сервере разработки, но с этим есть некоторые проблемы. В частности, внешний будет следовать за ревизией головы (мы не хотим устанавливать его на конкретную ревизию, так как это будет побеждать точку), и поэтому, если мы откроем более старые версии репозитория dev, определения externals по-прежнему будут указывать руководителю глобального репо, а не тому, как выглядел глобальный репо в возрасте нашей старой ревизии - таким образом, мы не сможем воссоздать старые выпуски, просто проверив старую ревизию.
- Другое решение состоит в том, чтобы задание cron периодически экспортировало последние ревизии из глобального репо и накладывало эти измененные файлы на рабочую копию из репозитория dev, а затем фиксировало изменения. Вероятно, этот шаг наложения и фиксации будет выполнен с использованием сценария
svn_load_dirs.pl, поставляемого с SVN. В идеале это должно быть сделано в качестве ловушки после фиксации в глобальном репо, но, опять же, по соображениям брандмауэра, глобальный сервер не может получить доступ к серверу dev, поэтому он должен выполняться машиной внутри брандмауэра (возможно, самой машиной сервера dev) , У этого подхода есть недостатки: сервер dev может быть устаревшим до тех пор, пока интервал в задании cron, и если кто-то случайно зафиксирует изменение на сервере dev, его изменение будет остановлено. (кроме того, если кто-то может придумать метод двунаправленной синхронизации, это было бы здорово!)
В настоящее время я склоняюсь к варианту 2, потому что он, кажется, приближает меня к тому, что мне нужно, насколько это возможно, но это все еще довольно плохой вариант. Это также, по сути, то, что мы делаем в настоящее время, с человеком вместо работы cron. Мои извинения за длинный пост. Большое спасибо за любую помощь, которую вы можете оказать.
Объяснение причин: Нам необходимо, чтобы эти общие файлы существовали в иерархии каталогов сервера dev, поскольку они являются обязательной частью нашего программного обеспечения, поэтому их должны иметь сборки, тестирование и т. Д. Я не могу предоставить доступ к dev-серверу через брандмауэр - я пытался убедить его в этом и потерпел неудачу. Я очень ясно дал понять лицам, принимающим решения, что наличие двух отдельных серверов для этого не то, как SVN предназначен для использования, и что, вероятно, будут проблемы. Чтобы помочь смягчить некоторые из проблем, которые мы предвидели, только глобальный сервер будет доступен для записи. Копия файлов на сервере разработчика будет концептуально доступна только для чтения (она будет изменена только при синхронизации изменений с глобальным сервером), но я не думаю, что смогу применить эту политику только для чтения с помощью средств управления доступом SVN, поскольку некоторые файлы в эта структура каталогов не будет существовать в глобальном репо, и, следовательно, должна быть редактируемой в dev, поэтому я не могу слепо заставить эту вещь только для чтения. Настройка режима «только для чтения» для каждого файла кажется недостижимой, поскольку их сотни, и они часто добавляются и удаляются.