Файлы шаблонов и контроль версий

Question

Есть ли способ иметь что-то вроде svn externals для файлов, хранящихся в системе контроля версий (желательно Subversion, но мне было бы интересно, возможно ли это или проще для других систем SCM).

Вот что я имею в виду. Скажем, у меня есть целая куча сценариев SQL, и они должны быть объединены в один большой сценарий для упаковки каждого выпуска. Было бы хорошо, если бы я мог создать файл для всех сценариев, а затем просто как-нибудь связать с другими файлами, и этот файл будет автоматически обновляться (после обновления SVN), когда какой-либо из упомянутых файлов изменится в Subversion. Полагаю, что связанный файл должен быть доступен только для чтения.

Думать об этом немного больше, имея слишком много файлов, вероятно, будет проще. Один для определения шаблона, а другой для самого файла.

Это может выглядеть примерно так.

Файл шаблона (возможно, расширение .sql.svntemplate или что-то в этом роде):

<external file="relative/repository/url/Script1.sql"/>
<external file="relative/repository/url/Script2.sql"/>
<external file="relative/repository/url/Script3.sql"/>
<external file="relative/repository/url/Script4.sql"/>

Конечно, это не обязательно должен быть XML.

Затем, когда вы добавляете и фиксируете файл .sql.svntemplate, Subversion автоматически создает файл только для чтения с тем же именем, за исключением расширения .svntemplate.

* 1016 Е.Г. *

DBScripts.sql.svntemplate

сгенерирует файл только для чтения с именем:

DBScripts.sql

который будет содержать содержимое всех сценариев.

Answer 1

То, что вы описываете, обычно известно как Производный объект , и многие системы контроля версий имеют разные способы обработки. В наиболее распространенном случае производные объекты создаются во время интеграции новой метки на этапе сборки. Обычными другими производными объектами являются скомпилированные объектные файлы, архивные файлы и файлы базы данных. Примером системы контроля версий, обрабатывающей производные объекты, является IBM Rational ClearCase.

В SVN не реализована хорошая обработка производных объектов. Я бы предложил создать файл make для действий перед коммитом. Поэтому перед проверкой svn вы запускаете make -f Makefile.commit, который создает / обновляет все соответствующие производные объекты. Вы можете поместить определенный Makefile в каждый каталог и включить в него make-файлы из подкаталогов, поэтому каждый раз, когда вы фиксируете поддерево, просто запустите make-файл в его каталоге, и он будет обновлять извлеченные объекты во всем поддереве, которое вы изменили. Вы можете добавить правила в make-файл для установки производных объектов только для чтения после их генерации.

О состояниях Makefile см. Пользователь gnu manual . Make - это инструмент, специально разработанный для обработки производных объектов на основе модификации исходного файла и зависимостей.