Переход от одного разработчика к нескольким в SVN

Чаще фиксируйте и обновляйте.

Конфликты должны происходить, если только не создаются/редактируются разные участки кода. Чем раньше возникают конфликты (и, следовательно, чем они меньше), тем лучше. Ежедневного совершения недостаточно.

В идеале коммиты должны быть атомарными изменениями. Наименьшее возможное изменение, добавляющее что-то в код при сохранении стабильности и корректности. Другими словами, если вы добавляете 3 разные функции, а затем фиксируете, коммиты, вероятно, недостаточно малы. У каждой функции должен быть свой коммит. (Или, если какая-либо из функций не мала, вероятно, более одного коммита.)

В идеале вы также должны попытаться сообщить, какие изменения будут происходить. То, насколько хорошо это работает на практике, сильно различается, но если вы знаете, что программист А будет сегодня работать над модулем X, то лучше избегать модификации кода модуля X без необходимости.

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

Изменить: я, вероятно, должен упомянуть, что я ни в коем случае не являюсь экспертом по svn-workflow. Я работал в команде из 4 человек, использующей git около 6 месяцев, и в команде из 2 человек, использующей svn в течение нескольких лет. Этот пост основан на вещах, которые, как я заметил, помогли или навредили нам с течением времени.

Ветвление не должно быть необходимым в вашей повседневной работе. Просто пусть все работают с файлами в основном исходном каталоге. Может быть разумно переместить код в подкаталог (например, «/trunk»), чтобы у вас также были другие каталоги в корне (например, каталог для ветвей).

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

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

Хорошее время для создания ветки — когда вы выпускаете свое приложение. Создайте ветку с именем 1.X для первого выпуска. Затем продолжайте работу в направлении 2.0 в багажнике. В ветке 1.Х можно собрать релиз 1.0, а также позже релиз 1.1 и так далее (не мешая работе в сторону 2.0 в багажнике).

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

В функциональной ветви изменения магистрали постоянно импортируются путем слияния. Когда функция завершена, вся ветвь объединяется с транком, и после этого ветвь не используется.

Release branches            __testing_1.X__..._rel_1.0___.._rel_1.1    ___2.X_branch_
                           /                                          /
___________trunk__________/_______trunk______________________________/____..
      \                                               /
       \_____really big feature for v2 only__________/ 

Feature branches

Для повседневной разработки вы можете использовать ветвление сколько угодно. Один из вариантов — одна ветвь на функцию, но вы, вероятно, обнаружите, что это создает больше проблем, чем решает для небольшой команды. Разрешать конфликты в SVN обычно намного проще, чем управлять несколькими ветвями и выполнять множество слияний. В других системах контроля версий (например, Git) ситуация иная.