Visual Studio 2008: как избежать ада слияния файла проекта?

Question

Когда вы работаете над проектом VS C # с несколькими разработчиками, которые все добавляют новые проекты и файлы в одно и то же решение, последний, кто попытается проверить его изменения, получает конфликты в файле решения проекта, которые нелегко слияния.

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

Мне интересно, есть ли более простой способ сделать это. Читайте: я могу заставить VS / TFS / merge сделать это для меня?

Answer 1

Мое предложение будет обновляться и фиксироваться чаще. В частности, убедитесь, что вы запустили Get Latest, прежде чем ожидали каких-либо изменений в файле решения.

«Слияние ада» с такими вещами, как XML и текстовые файлы (которыми являются все файлы проекта и решения), обычно происходит только потому, что люди пытаются зафиксировать отдельные очень большие изменения.

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

Answer 2

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

Его можно найти по адресу: http://slntools.codeplex.com/

Answer 3

Мне тоже очень надоели проблемы слияния с файлами проекта. (В какой-то момент я пытался разрешить более 9000 конфликтов в одном файле проекта.)

Так что я сделал с этим что-то: http://www.projectmerge.com

Хотя это началось как инструмент сравнения / объединения файлов проекта, он быстро превратился во что-то, что может сравнивать и объединять любой файл XML.

Надеюсь, вы найдете это полезным.

Answer 4

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

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

Answer 5

Одно предложение добавить в пул комментариев ...

Работайте над тем, чтобы свести к минимуму изменения, которые вы вносите в файл SLN при фиксации, чтобы другим было легче объединяться.

(Конечно, то же самое касается и других).

Для иллюстрации предположим, что ваш SLN-файл в настоящее время содержит четыре проекта:

SLN: A, B, C, D

Вы и сотрудник вносите изменения. Вы добавляете проект E, плюс (по какой-то причине) вещи переупорядочиваются:

Yours:  A, E, D, C, B

Изменения ваших коллег включают добавление проекта F:

Co-Worker: A, B, C, D, F

Если вы передадите свои изменения как есть, тогда вашему коллеге придется столкнуться с объединением этих двух элементов:

SLN: A, E, D, C, B
Co-Worker: A, B, C, D, F

Насти.

Вместо этого, если вы (осторожно!) Работаете над минимизацией различий, вы можете сделать свою рабочую копию похожей на эту:

Yours:  A, B, C, D, E

В этом случае, когда вашему коллеге нужно объединиться, ему придется столкнуться с этим:

SLN: A, B, C, D, E
Co-Worker: A, B, C, D, F

Гораздо проще слить.