Visual Studio 2008: как избежать, чтобы файл проекта объединил ад?

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

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

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

7
задан Richard J. Ross III 13 March 2013 в 14:07
поделиться

4 ответа

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

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

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

19
ответ дан 6 December 2019 в 06:36
поделиться

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

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

1
ответ дан 6 December 2019 в 06:36
поделиться

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

Поработайте над минимизацией изменений, которые вы вносите в файл 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

Намного проще слить.

0
ответ дан 6 December 2019 в 06:36
поделиться

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

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

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

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

1
ответ дан 6 December 2019 в 06:36
поделиться
Другие вопросы по тегам:

Похожие вопросы: