Как вы управляете файлами .vcproj в системе управления версиями, которые изменяются несколькими разработчиками?

Question

Мы используем Subversion в качестве нашей системы управления версиями и храним файлы проекта VisualStudio (vcproj) в системе управления версиями, как я думаю, это нормально.В Subversion мы не используем какую-либо форму блокировки файлов, поэтому, если два разработчика работают над одним и тем же проектом одновременно и оба добавляют файлы в проект или изменяют настройки, второму, кто фиксирует, приходится объединять изменения.

Как вы объединяете эти изменения?

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

Способы, о которых я могу думать, следующие

• Получите последнюю версию из svn и повторно добавьте все локальные изменения вручную
• Отредактируйте файл вручную, чтобы разрешить любые конфликты, возникшие в результате автоматического слияния
• Внедрите некоторую форму схемы блокировки для предотвращения одновременных изменений
• Заключите соглашение между разработчиками, чтобы они не вносили одновременных изменений

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

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

Answer 1

Я обнаружил, что вариант 2 (редактирование файлов вручную) обычно работает довольно хорошо, если вы используете хороший инструмент diff (я использую ВинМердж).Основная проблема, с которой я столкнулся, заключается в том, что Visual Studio иногда изменяет порядок файлов.Но, если у вас есть хороший инструмент для разделения / слияния, то он должен уметь различать измененный контент и перемещенный контент.Это может очень помочь.

Answer 2

Вы могли бы найти Проект:Слияние или Инструменты для SLN-файла полезный

Answer 3

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

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

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

Answer 4

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

Здесь есть только одно предостережение:Заходите почаще!Если вы внесете серьезные изменения в структуру проекта и не внесете их немедленно, эти изменения могут начать усугублять сложность последующих слияний.Если я вношу серьезные изменения в структуру проекта, я обычно предупреждаю всех.Я попрошу их всех проверить свою текущую работу, а затем сам позабочусь о слиянии.

Answer 5

Я нашел это недавно: http://www.codeproject.com/KB/macros/vcproj_formatter.aspx Если вы запустите этот инструмент в файле vcproj и в его модифицированной версии, вы сможете легко объединить их вместе с помощью вашего любимого инструмента слияния текста, и, кроме того, в результате получится более компактный симпатичный файл vcproj.

Answer 6

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

Я думаю, что в этой ситуации в настоящее время нет волшебного средства - иногда слияние доставляет боль.

Answer 7

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

Одновременные изменения к проекту все в полном порядке, пока люди общаются.