Когда для фиксации контроля версий требуется, чтобы разработчик изменил свою собственную конфигурацию - PullRequest
Новая
       7

Когда для фиксации контроля версий требуется, чтобы разработчик изменил свою собственную конфигурацию

6 голосов
/ 22 августа 2011

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

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

Как другие люди делают это, или никогда не должно быть никаких необходимых изменений, которые находятся вне контроля версий?

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

Ответы [ 5 ]

6 голосов
/ 22 августа 2011

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

5 голосов
/ 22 августа 2011

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

enter image description here

Драйвер фильтра:

  • объявлено в .gitattributes файлах (то есть, в отличие от хуков или триггеров, вы можете легко распространять его)
  • , прикрепленных к нечеткому изображению и чистому сценарию (также с версиями, один из которых запускаетсяпри фиксации.
  • вы можете, при фиксации, запускать любые необходимые вам автоматические действия.

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

3 голосов
/ 22 августа 2011

Лично я использую 2 метода:

  1. коммуникационный: я говорю другим разработчикам, что нужно делать, чтобы быть в курсе (правильно, но иногда мы упускаем некоторые детали ....)
  2. сценарий: я создал сценарий update, который используется для управления обновлением всех частей моего проекта (разные каталоги, разные репозитории, другой контроль версий ...), в этот сценарий я помещаю каждую операцию необходимо поддерживать правильный репозиторий (я использую его для svn и git репозиториев).
2 голосов
/ 22 августа 2011

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

возможно с крючками

1 голос
/ 23 августа 2011

Для файлов, в которых каждый разработчик должен вносить локальные изменения (например, строки подключения к базе данных и т. Д.), Мне нравится сохранять шаблон в виде отслеживаемого файла, что-то вроде localconfig.template. В ваших сценариях сборки / запуска у вас может быть такая логика: 

if not exists localconfig then
  copy localconfig.template to localconfig
else
  if localconfig.template is newer than localconfig
    print a big ugly warning about maybe needing to update
...