Каков наилучший способ для svn 2 копии одного и того же проекта?

Question

Я работаю над проектом, который выполняется в двух местах, одно на активном сервере, а другое в локальной тестовой среде.Эти 2 копии отличаются только некоторыми конфигурационными файлами (в которых хранятся имена, URL, информация о базе данных и т. Д.) В нескольких местах.

Теперь я работаю так:

1. сделать некоторые изменения в локальной копии, протестировать новую версию в локальной тестовой среде, если все в порядке, svn commit;

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

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

Answer 1

Вы можете хранить два разных файла и использовать символические ссылки на один из них.

project
  |-configuration
  |  |-development.cfg
  |  \-production.cfg
  \-config.cfg < symbolic link to configuration/development.cfg

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

Answer 2

Создайте три файла конфигурации:

• общий
• тест
• Производство

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

Это позволяет разделить конфигурацию (и вы можете подготовить производственную конфигурацию на своей машине для разработки или даже протестировать ее там).

Теперь вам просто нужно добавить опцию командной строки. Если опция есть, читается общий + производственный конфиг. Если он отсутствует (во время разработки), используется конфигурация common + test.

Answer 3

1. Если вы используете одно хранилище для обоих серверов, вы можете подумать о разделении на две (ветви) внутри одного репо и объединении изменений позже между ветвями
2. Для конфигурационных файлов в ветках вы можете подумать (?) О перемещении конфигов в отдельный каталог, определите этот каталог как внешний для родительского репо и используйте относительный (не абсолютный) путь в svn: externals или указать разные PEG-версии (подготовленные) для общего URL внешних ссылок

Answer 4

Вы должны поддерживать столько ресурсов, сколько сможете, поименованных ресурсов JNDI. Вы можете настроить свои тестовые и prod-серверы с одним и тем же именем JNDI перед различными значениями. Ваше приложение не должно меняться таким образом.

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