зеркалирование подпапки между двумя перезаписываемыми SVN-репозиториями

Question

У меня есть ситуация, с которой я пытаюсь справиться с участием SVN-сервера моей компании. Мы сохраняем весь наш важный код на заблокированном сервере (мы будем называть это «dev» сервером). Есть некоторые файлы, которые необходимо отредактировать пользователям за пределами корпоративной сети, поэтому у нас есть еще один сервер SVN («глобальный» сервер), который доступен за пределами брандмауэра и содержит копии этих каталогов, содержащих файлы, необходимые извне. Если это имеет значение, структура папок глобального сервера является подмножеством сервера dev (т. Е. Это всего лишь несколько файлов/каталогов выбора, но все они имеют одинаковые относительные пути и т. Д.). Я включил краткое объяснение , почему мы пытаемся сделать это в конце сообщения, если вы хотите его прочитать, но поверьте мне, это нужно сделать на двух отдельных серверах.

На первый взгляд svnsync кажется идеальным для этой работы, но у него есть неудачная проблема в том, что это единственное, что модифицирует репозиторий назначения. Очевидно, что это не сработает, поскольку наш репозиторий dev сильно используется.

Мне кажется, что есть два решения, и ни одно из них не является хорошим решением. Я надеюсь, что кто-то может помочь мне настроить один из них или, лучше сказать, предоставить альтернативу.

1. Моей первой идеей является использование внешних ресурсов в dev-сервере, но в этом есть некоторые проблемы. Прежде всего, внешний будет следовать за пересмотром главы (мы не хотим указывать его на конкретную ревизию, так как это победит точку), и поэтому, если мы подтянем старые версии dev-repo, определения externals будут по-прежнему указывать к главе глобального репо, а не к тому, как выглядело глобальное репо в эпоху нашей старой редакции, - таким образом, мы не сможем воссоздать старые версии, просто проверив старую ревизию.
2. Другое решение состоит в том, чтобы задание cron периодически экспортировало последние версии (ы) из глобального репо и накладывало эти измененные файлы на рабочую копию из dev-репо, а затем фиксировало изменения. Вероятно, этот шаг наложения и фиксации будет выполнен с использованием сценария svn_load_dirs.pl, который поставляется с SVN. В идеале это можно было бы сделать как привязку post-commit к глобальному репо, но опять же по причинам брандмауэра глобальный сервер не сможет получить доступ к серверу dev, поэтому он должен выполняться машиной внутри брандмауэра (возможно, самой машиной dev-сервера) , Этот подход имеет свои недостатки: сервер dev может быть устаревшим до тех пор, пока интервал на задании cron, и если кто-то случайно совершит изменение на dev-сервере, их изменение начнется. (как в стороне, если кто-то может придумать метод двунаправленной синхронизации, это было бы замечательно!)

Я сейчас склоняюсь к варианту 2, потому что это, кажется, приближает меня к тому, что Мне нужно как можно больше, но это все еще неплохой вариант. Это также, по сути, то, что мы делаем в настоящее время, с человеком вместо работы cron. Приношу свои извинения за длинный пост. Большое вам спасибо за любую помощь, которую вы можете предоставить.

Объяснение почему: Нам нужны эти общие файлы для существования в иерархии каталогов dev-сервера, потому что они являются обязательной частью нашего программного обеспечения, поэтому их сборки, тестирование и т. Д. Должны иметь их. Я не могу разоблачить dev-сервер через брандмауэр - я пытался убедить власти, которые были и не смогли. Я ясно дал понять лицам, принимающим решения, о том, что наличие двух отдельных серверов для этого не означает, что SVN предназначен для использования и что, скорее всего, будут проблемы. Чтобы облегчить некоторые из проблем, которые мы предусмотрели, только глобальный сервер будет доступен для записи. Копия файлов сервера Dev будет концептуально доступна только для чтения (только при изменении синхронизации с глобального сервера), но я не думаю, что могу фактически применить эту политику только для чтения с элементами управления доступом SVN, потому что некоторые из файлов в эта структура каталогов не будет существовать в глобальном репо и, следовательно, должна быть доступна для редактирования в dev, поэтому я не могу слепо сделать это только для чтения.Установка только для чтения на основе каждого файла кажется недостижимой, поскольку есть сотни, и они часто добавляются и удаляются.

Answer 1

Вы можете попытаться настроить прокси-прокси, чтобы все записи в вашем общем репозитории автоматически перенаправлялись на частный сервер.

Я никогда этого не делал, но here - это документация по этому вопросу.

Answer 2

Вместо того, чтобы усложниться здесь, на контроле источника, возможно, стоит потратить на разделение двух репозиториев (удаление кода, который живет в глобальном от dev), а затем сборку dev потребляют сборки глобального. Так как ваши внутренние люди смогут взять на себя оба, и иметь один и тот же код, живущий в обоих, навсегда это трудно.

Вы не упомянули о инструментах, связанных с языками ... так что трудно понять, как это будет соответствовать. Подумайте о том, как глобально публиковать артефакт (ы), а затем построить глобальное решение этой зависимости.

Одна вещь, о которой вы не упоминали в альтернативе 2, вы потеряете контрольный журнал, поскольку пользователь, который совершает глобальный, не будет пользователем, который накладывает и обязывает dev.