Есть ли в какой-либо системе контроля версий функция «только локальные изменения»?

Question

Этот вопрос возник у меня во время игры с git, но я задам общий случай ...

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

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

1. Редактировать войны в управлении версиями. Просто продолжайте изменять файл и надейтесь, что все остальные перестанут редактировать файл, прежде чем вы сделаете.

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

3. Шаблон это. Удалите файл из системы контроля версий и проверьте его копию с .template на конце. Локально скопируйте файл и переименуйте его обратно с изменениями.

4. Используйте новую (вымышленную?) Функцию постоянных локальных изменений. Внесите изменения, затем выполните команду record-changes-as-local-persistent, которая определяет исправление и после каждого обновления повторно применяет исправление.

Существует ли эта функция где-нибудь (похоже на git stash, но цель немного другая)? Если его нет, есть ли хорошая причина, почему нет? (кто-то думал об этом и решил, что это плохая идея?)

Answer 1

Вы можете сделать это в git с основной (или «вендорной») веткой и локальной веткой. Ваши локальные коммиты идут в локальную ветку, и вы изменяете их поверх мастер, когда они меняются. Если вы не укажете пульт дистанционного управления для локальной ветки, вы не сможете его случайно нажать; если вы случайно передали что-то, что вы хотите сохранить в локальной ветке, просто выберите команду master и нажмите оттуда.

Answer 2

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

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

Answer 3

Это может быть немного более специфично для 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 для управления своими выпусками, этого легко добиться, просто скопировав правильный конфиг.

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

Answer 4

Вы можете игнорировать любой файл конфигурации из системы контроля версий. Это файл .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' %>

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

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

Answer 5

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

Answer 6

Вы можете сделать это с помощью SVN.

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

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

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

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

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

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

Answer 7

я делаю аналогичную вещь на монотоне , используя команду propagate.

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

Answer 8

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

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

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

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

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

Answer 9

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

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

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