Как SVN v 1.8 разветвляется/сливается по сравнению с Git?

Я использовал Git какое-то время и недавно спросил, почему его возможности слияния и разветвления лучше, чем у SVN. Несколько лет назад, когда я использовал SVN, я обнаружил, что ветвление и слияние были довольно громоздкими и подверженными ошибкам операциям. В результате я едва разветкился. Однако, только на прошлой неделе я попробовал новую версию SVN 1.8, и я узнал, что это делало все довольно хорошо.

Я действительно пробовал некоторые сложные ветвящиеся вещи, и у меня не было смешных ошибок. Конечно, это было очень медленно, но моя главная забота - о функциональности, а не скорости (по крайней мере, когда пытаешься кого-то убедить).

Итак, мой вопрос в том, насколько отличаются SVN v1.8 и Git возможности ветвления/слияния. В частности, мне также было бы интересно узнать, есть ли какие-либо ветвящиеся операции и операции слияния (или рабочий процесс), которые могут быть выполнены с помощью Git, но не с SVN (или, возможно, это может быть выполнено с помощью SVN, но это довольно сложно).

Ответы

Ответ 1

Важно понять модель, используемую движком слияния Subversion. Он сильно отличается от Git.

Subversion поддерживает два основных типа слияний. Первый - это слияние "sync", которое выполняется, чтобы поддерживать ветвь разработки (функция/задача/тема) в актуальном состоянии с помощью соединительной линии. Второй - это "реинтеграция" слияния, которое используется для продвижения готовой работы к стволу. Таким образом, модель является моделью магистрали (магистрали), которая поддерживает ветки функций и ветки выпуска.

Важным ограничением является то, что Subversion не рассматривает полную DAG при поиске истории слияния, чтобы найти правильную базу слияния. Слияние между непосредственно связанными (родительско-дочерними) ветвями хорошо поддерживается, но слияния между ветвями, отдаленными предками или братьями и сестрами, с косвенным вкладом из других отраслей, часто дают неожиданные результаты.

Поддержка слияния Subversion со временем улучшается, как вы заметили. Он не имел никакого отслеживания слияния вообще до 1,5, совершил огромные скачки в 1,8, а предстоящие версии 1.9 улучшат отслеживание переименования/перемещения. Там также говорят о "локальных полках" в будущем.

(Кстати, я знаю кое-что из этого, потому что я присутствовал на конференции Subversion/ Git Live на прошлой неделе, и коммиттер, который работает над движком слияния, дал презентацию.)

Git, с другой стороны, имеет очень уважаемый механизм слияния. Он может обрабатывать слияния практически любой сложности. На самом деле его единственным основным ограничением слияния является то, что он выводит move/renames после факта. В очень сложных ситуациях рефакторинга он может не подобрать все правильно.

Подводя итог:

Оба Subversion и Git будут хорошо работать в общих сценариях слияния.
Git будет обрабатывать более сложные сценарии слияния более эффективно, особенно при слиянии ветвей, у которых нет прямого отношения родитель-потомок.
Обе системы имеют проблемы с отслеживанием переименований/перемещений во время рефакторинга, хотя Git, вероятно, делает лучшую работу в типичных случаях.
Git Команда merge проще запускать в простых случаях. Обе системы могут иметь крутую кривую обучения, если вы делаете необычные операции.
Git поддерживает связанные операции, такие как перезагрузка и слияние репозиториев, которые могут улучшить ваш рабочий процесс в некоторых случаях.
Чтобы наилучшим образом использовать Subversion, убедитесь, что у вас есть сервер и клиенты с более высокой вероятностью.

Надеюсь, что это поможет!

Ответ 2

Несколько вещей spring для ума.

Git поддерживает частные ветки, которые AFAIK SVN не делает.
Git активно поддерживает рабочие процессы, в которых один или несколько членов команды разрабатывают, возможно, умиротворяющие или конфиденциальные ветки с фиксацией контроля версий и совместной работы без участия членов подгруппы без "публикации" работы остальной части команда и без сложных элементов управления ACL, чтобы заблокировать некоторые ветки от доступа к остальной части команды.
С git и несколькими разработчиками вы всегда можете восстановить свои репозитории (или большинство из них), в комплекте с историей в случае сбоя, который не будет уничтожен для каждой машины-разработчика, с SVN, если что-то случится с основного сервера/репозитория, тогда все зависит от вашей политики резервного копирования.

Я уверен, что их гораздо больше.