Visual Studio, SVN и объединение файлов .csproj и .sln

Question

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

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

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

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

Answer 1

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

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

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

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

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

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

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

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

Answer 2

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

VisualSVN заблокирует Visual Studio во время операции обновления и обеспечит автоматическую перезагрузку любых измененных проектов, чтобы пользователи не могли игнорировать внешние изменения.

Answer 3

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

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

Пример:

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

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

Answer 4

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

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

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

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

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

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

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

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

Answer 5

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

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

FiSSH