>раскройте понятие секса с ветками. По моему мнению, если файл был
>модифицирован и в ветке и в транке, это должно быть зафиксировано,
>и именно конфликтом, именно дифом. В git проще управлять разработкой, разнесённой по веткам, нежели чем в svn. Попробовав git я с уверенностью могу сказать, что работа с бранчами в svn - это секс :)
Ну для сравнения:
1) Создаём ветку:
git branch new_branch_name
svn cp trunk branches/new_branch_name
2) Переключаемся в ветку:
git checkout new_branch_name
cd branches/new_branch_name
3) Поработали, обнаружили что основная "стволовая" ветка обновилась, да так, что желательно получить её функционал в бранче:
git rebase master
svn merge r???:??? (тут игра в сапёра. Во-первых, не ошибиться бы с номерами коммитов. Во-вторых, коммиты в ветке окажутся позади отмерженного)
Вот уже тут чувствуется разница. Особенно если придётся конфликты разгребать. Наилучший выход здесь с svn: получить патчи (один патч = один коммит) из ветки, пересоздать ветку с транка (или откатить свои коммиты и отмержить новые коммиты с транка) и вручную наложить сохранённые патчи.
4) Перестраиваем коммиты, ибо было туча промежуточных с отладкой (чтобы другие девелоперы ознакомились с мыслями и догадками):
git rebase -i master # потом в интерактивном режиме сливаем коммиты, меняем описание, редактируем и т.д.
svn ???? Опять пляски с патчами?
5) вливаем бранч в стволовую ветку:
git checkout master; git merge new_branch_name
svn merge r???:??? (Опять же - ошибка в номерах и "опа").
Это из личных ощущений. Если у Вас опыта работы с svn поболее моего - буду рад увидеть Ваши приёмы работы с svn.
