Visual Studio, svn и слияние.csproj и.sln файлов

У кого-нибудь был успех, чтобы SVN объединил проект Visual Studio (.csproj файл) или решение (.СЛН) файлы, которые были отредактированы двумя пользователями? Пример

  1. пользователь A проверяет проект
  2. пользователь B проверяет тот же проект
  3. пользователь A добавляет файл
  4. пользователь A фиксирует изменения
  5. пользователь B добавляет файл
  6. пользователь B фиксирует изменения

Мне кажется, что на шаге (6), svn, Tortoise, Ankh или что-то еще должно обнаружение конфликта и автоматическое слияние двух файлов проекта или, что более вероятно, приглашение пользователя B разрешить конфликт. В настоящее время мы видим изменения, сделанные пользователем a, уничтоженные при регистрации Пользователя B, что приводит к плохим сборкам, развертываниям и т. д. отсутствующие функции, которые были добавлены до последней проверки.

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

7
merge svn visual-studio

5 ответов

Как вы думаете, вы обмануть SVN в выполнении шага #6? Кажется, вы неправильно поняли, что происходит. SVN никогда не будет совершать из рабочей копии, которая не обновлена, поэтому Шаг #6 не будет работать без предварительного обновления пользователя B и слияния изменений пользователя A. Честно. Попробовать его.

Я думаю, что вместо этого происходит вот что:

  1. проверяет проект.
  2. B проверяет тот же проект.
  3. a добавляет a файл.
  4. а совершает изменения.
  5. B добавляет файл, но забывает сохранить проект/решение.
  6. B пытается зафиксировать изменения и получает сообщение, он должен обновить.
  7. B обновления.
  8. B переключается обратно на VS. VS говорит ему, что проект / решение изменилось на диске и спрашивает, хочет ли он a) перезагрузить с диска и потерять свои изменения b) переопределить версию на диске.
  9. B не понимает, не пытается понять, считает его изменения ценными и выбирает b), переопределяя изменения на диске.
  10. B по-прежнему не пытается понять и, таким образом, не отличается от версии, которую он имеет на диске с последним совершенным, и, таким образом, пропускает, что он преодолел изменения A.
  11. B регистрируется, переопределяя изменения A.

Я видел, как это происходит время от времени, обычно с пользователем B, который действительно не понимает рабочий процесс SVN (или CVS, FTM).

Итак, вот несколько подсказки:

Не обновлять, если вы не сохранили все ("Файл" - >" Сохранить все"; для меня это Ctrl+Shift+S). В случае, если вы сделали эту ошибку, и вы застряли, переопределите изменения на диске, а затем объединить потерянные изменения вручную. (Он также может работать, чтобы обновить файл проекта/решения до версии N-1, а затем снова возглавить, чтобы SVN выполнил слияние.)

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

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

32

Я второй ответ sbi. Одно из возможных решений - всегда обновлять из Visual Studio, по крайней мере, если вы используете VisualSVN (я не уверен, как AnkhSVN справляется с этой ситуацией).

VisualSVN заблокирует visual studio во время операции обновления и убедитесь, что все измененные проекты автоматически перезагружаются, поэтому пользователи не могут игнорировать внешние изменения.

2

довольно радикальное, но эффективное решение-использовать инструмент для создания этих файлов решений из мета-определения, а затем помещать только мета-определение под контроль источника, а не файлы проектов Visual Studio (которые являются кошмаром для слияния).

в своей команде мы используем MPC для этого. У нас есть:

  • куча .mpc файлы для описания проектов,
  • a .файл mwc для описания рабочего пространства / решения,
  • небольшой .УМК создание файлов Visual Studio.

Так как все они вручную отредактированные текстовые файлы, у нас больше нет проблем с Visual Studio, смешивая все.

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

  • конфигурации проекта централизованы: например, изменение флага компиляции выполняется в одном месте, а не на за основу проекта,
  • это может вместить несколько систем сборки (в настоящее время мы используем Visual 2003 и 2005, но это также работает с gcc и другими).

по моему опыту, хотя настройка инструмента может быть немного болезненной (но все зависит от размера и сложности вашего проекта), это того стоит.

обратите внимание, что MPC не единственный инструмент для этой цели. Существуют и другие, такие как CMake.

1

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

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

пример:

<ItemGroup>
  <Compile Include="Src\**\*.cs" />
  [...]
</ItemGroup>

грустно, что Visual Studio не поощряет такого рода настройку проекта и вместо этого выбирает список отдельных файлы.

1

Это очень утомительно и утомительно, поэтому вам просто нужно пропахать его. Иногда вы сохраняете локальную рабочую копию, поскольку в нее добавлены все ваши пользовательские проекты. Однако в других случаях вы захотите объединить все новые элементы из базового решения, чтобы получить все из обоих файлов решения. Для удобочитаемости лучше всего разместить все дополнения базового продукта перед добавлениями настройки.

Не беспокойтесь, что первая часть GUID идентична для проекты, но это последняя часть, которая будет уникальной.

Fissh

0