Какая-либо система управления версиями имеет “персистентный локальный, только изменяют” функцию?

Вы можете игнорировать любой файл конфигурации из системы контроля версий. Это файл .gitignore .

Например, если вы хотите игнорировать весь каталог журналов, вы добавляете в этот файл строку:

log/*

Чтобы игнорировать файл .DS_Store, вы добавляете строку с помощью:

.DS_Store

Затем вы можете обновить файл локально, вы никогда не увидите его в измененных, но незафиксированных файлах. И если вы выполните git add. , он не будет добавлен в коммит.

Если вам нужно поместить файл конфигурации в git, но сохранить только один пароль или переменную где-то вне его, что я делаю, это вызываю удаленный файл внутри этого файла конфигурации. И этот файл содержит мой пароль.

Например, в проекте rails конфигурация моей базы данных выглядит так:

production:
 database: project_database
 username: database_user
 password: <%= File.read('path/to/my/password/file').chomp if File.readable? 'path/to/my/password/file' %>

Файл «путь / к / моему / паролю / файлу» не находится в системе контроля версий.
Итак, мой файл конфигурации имеет версии. Но пароль зависит от машины, на которой мы находимся.

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

Это может быть немного более специфичным для Visual Studio, но я предполагаю, что в большинстве IDE будет какая-то похожая функция.

Во всех моих конфигурациях приложений / веб-приложений, которые имеют настройки, изменяющиеся для разных сред Я разделил их на отдельные файлы, чтобы моя основная конфигурация выглядела так

  <dataConfiguration configSource="Config\Development\dataConfiguration.config" />
  <connectionStrings configSource="Config\Development\connectionStrings.config" />
  <appSettings configSource="Config\Development\appSettings.config"/>

Затем для каждого файла она была похожа на

<?xml version="1.0" encoding="utf-8" ?>
<dataConfiguration defaultDatabase="defaultDatabase"/>

. После этого я создаю папки для каждой среды Dev / Staging / Prod и т. Д. И использую другой вспомогательный файл конфигурации в каждую папку, чтобы все настройки можно было проверить в TFS. У меня есть настройка проекта веб-развертывания для извлечения соответствующих файлов для каждой конфигурации выпуска. Позже, когда я настрою TFS для управления моими выпусками, этого легко добиться, просто скопировав правильную конфигурацию.

Darcs предоставляет это. Вы можете записать патч изменений настроек в вашем локальном репозитории и никогда не передавать его в другой репозиторий. К сожалению, в часто задаваемых вопросах говорится , что нельзя пометить патч только как локальный.

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

Я делаю то же самое на monotone , используя команду распространять .

короче говоря, у меня есть ветка «разработка» и «развернутая» ветка. в развернутой ветке конфигурация имеет несколько других настроек (некоторые каталоги и DEBUG = False). Когда я хочу развернуть, я делаю mtn распространять от разработки до развернутой ветви. затем на сервере я выполняю извлечение и обновление, поэтому рабочая область получает последние изменения из своей ветви, которые включают все новые разработки, но с учетом различий в настройках.

Я всегда обращал внимание на эту проблему, работая над тем, чтобы избежать такой ситуации.

Я стараюсь сделать все среды как можно более похожими друг на друга. Единственное, что обычно отличается, - это имена входа, а иногда и URL-адреса служб инфраструктуры (БД, брокер сообщений, службы данных предприятия и т. Д.).

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

Пароли и конфигурация для CI и тестовых сред проверяются, поэтому серверы сборки и развертывания могут автоматически запускать системы в тестовые среды.

Пароли для производства никогда не проверяются (что '

Вы можете вроде как сделать это с SVN.

Если вы извлечете файл из библиотеки и внесете в него изменения, а затем выполните «обновление», вы получите новая копия файла из библиотеки с внесенными в нее изменениями. Я регулярно использую это для файлов конфигурации.

Это не совсем похоже на то, что вы описываете, потому что каждый раз, когда вы делаете коммит, вам нужно исключить файл конфигурации. Я полагаю, если вы забудете сделать это в какой-то момент, вы обновите репозиторий своими локальными изменениями и причините всем остальным неприятности.

И когда вам действительно нужно изменить «публичную» часть файла конфигурации, у вас есть чтобы сделать отдельную проверку, чтобы можно было отделить "общедоступные" изменения от "локальных".

I ' Я также поддерживаю схемы, подобные описанию Криса Марисика. У меня есть пара веб-приложений, в которых я создал несколько файлов конфигурации, и программа динамически решает, какой из них использовать, в зависимости от среды.

В одном случае файл конфигурации включает пути к внешним файлам, и я работал как с сервером Windows, так и с сервером Linux, поэтому имена путей разные. В итоге я создал «конфигурацию Linux» и «конфигурацию Windows», а затем выбрал, в зависимости от того, в какой ОС я работал.

В другом случае программа при запуске проверяет имя контекста сервлета (это приложение JSP / сервлет), затем ищет файл с именем «WEB-INF / .properties». Если он этого не находит, он загружает имя по умолчанию.

Mercurial может добавить локальный файл в .hgignore и, таким образом, быть проигнорированным - тогда он не будет портить ваши измененные файлы или что-то еще.

Это выполнимо, если вы можете объединить несколько репозиториев в одно рабочее дерево. Самым простым решением были бы символические ссылки.

Проблема (которая усложняет задачу) состоит в том, что VCS хотят сохранить понятие наборов изменений. Итак, если вы фиксируете такой файл вместе с обычными версионными файлами - должны ли изменения принадлежать набору изменений или нет? Наличие одного и того же набора изменений означает разные вещи на разных машинах, что явно сбивает с толку.

С несколькими репозиториями вы, безусловно, можете иметь коммиты, которые идут в один репозиторий или другой. Сколько для этого потребуется локальной настройки, зависит от системы VCS. Например, для svn: externals вам нужно будет использовать один и тот же репозиторий file: на каждой машине, но они могут указывать на разные наборы файлов. С символическими ссылками,