Битва VS2012 и VS2013 из-за заголовка .sln

Я разрабатываю Visual Studio 2012, а другой разработчик — 2013. Когда мы делимся кодом на git, каждая версия Visual Studio меняет заголовок .sln по своему вкусу. Мы получаем такие изменения практически при каждом коммите:

@@ -1,8 +1,6 @@
 <U+FEFF>
 Microsoft Visual Studio Solution File, Format Version 12.00
-# Visual Studio 2013
-VisualStudioVersion = 12.0.30110.0
-MinimumVisualStudioVersion = 10.0.40219.1
+# Visual Studio 2012

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

Обратите внимание, что добавление файла решения в .gitignore — плохая идея, поскольку действительные изменения не так уж редки.


git visual-studio-2013 solution visual-studio-2012
person StackExchange saddens dancek    schedule 12.03.2014    source источник
comment
У меня такая же проблема с 2010 и 2012 годами. Так как я в меньшинстве пользователей 2012 года, я просто никогда не проверяю опасные изменения. Однако это редко встречается, и для некоторых вещей в файлах .vcxproj (например) мы смогли использовать условный код, чтобы заставить его работать гладко в обеих IDE.   -  person pattivacek    schedule 12.03.2014
comment
Мы находимся на начальной стадии проекта, и кажется, что каждая третья фиксация включает в себя реальные изменения в файлах проекта/решения. Я предполагаю, что простое отсутствие решения становится реальной альтернативой позже.   -  person StackExchange saddens dancek    schedule 12.03.2014
comment
git add -p пригодится и в подобных ситуациях. Это правда, я не сильно возился с файлами решения/проекта, но когда я это делаю, я почти всегда прибегаю к git add -p, просто чтобы убедиться, что я не затопчу что-то важное.   -  person pattivacek    schedule 12.03.2014

Ответы (1)


arrow_upward
1
arrow_downward

Я собираюсь пойти дальше и ответить, чтобы обобщить знания, которые у меня есть по этому вопросу. В какой-то степени я думаю, что это нерешенная проблема с git. Стандартный ответ: «Не загружать двоичные файлы и метаданные в VCS», но иногда реальность такова, что вам нужно поделиться некоторым количеством информации о конфигурации IDE/компиляции, но вам необходимо поддерживать несколько компиляторов/ОС/версий/и т. д.

Очевидно, что .gitignore полезен для всего, что действительно зависит от пользователя или сгенерировано компилятором. Вы можете довольно легко определить, какие элементы следует игнорировать, или просмотреть множество списков, доступных в Интернете для разных компиляторов и IDE.

Однако некоторые файлы необходимы, но все же зависят от факторов, которые меняются от пользователя к пользователю или от машины к машине. По моему опыту, .vcxproj файлы проекта Visual Studio C были нарушителями в этом ключе. Проблема в том, что VS2010 и VS2012 хотят использовать разные версии файла PlatformToolset. Решение заключалось в использовании условных операторов:

<PlatformToolset Condition="'$(VisualStudioVersion)' == '10.0'">v100</PlatformToolset>
<PlatformToolset Condition="'$(VisualStudioVersion)' == '11.0'">v110</PlatformToolset>

Я не думаю, что эта идея будет работать в вашем конкретном случае, но, вероятно, она будет работать во многих случаях. В вашей ситуации, я думаю, вы должны решить, какой будет «каноническая» версия (т.е. выбрать компилятор/IDE/версию/компьютер/что угодно по умолчанию), а затем в любой ситуации, которая отклоняется от этого, нужно будет избегать проверки в конфликтующих разделах. . Самый простой способ сделать это — использовать git add -p либо для всех ваших изменений, либо только для файлов, о которых известно, что они вызывают проблемы. Добавляйте только те части, которые полезны для всех, а для остальных, если они мешают перебазированию или чему-то еще, вы можете либо git stash их, либо взорвать их с помощью git checkout -- <filename> после того, как вы закоммитите важные части.

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

person pattivacek    schedule 20.03.2014
comment
Спасибо за информативный ответ! Я рад, что у нас нет подобных проблем с нашими .csproj файлами :) - person StackExchange saddens dancek; 24.03.2014
comment
Без проблем! Я бы хотел, чтобы было более элегантное решение, но я никогда о нем не слышал, поэтому я просто собрал все советы, которые смог придумать и найти. Надеюсь, это поможет. :) - person pattivacek; 24.03.2014