Как поддержка ветвления и слияния в dvcs (git / mercurial) лучше, чем в svn?

Question

Множество статей о системах dvcs заявляют о превосходной поддержке ветвления и слияния как одной из причин перехода от систем svn к dvcs. Как именно эти системы делают ветвление и слияние по-разному, что делает его лучше?

Answer 1

Исторически разница между отслеживанием слиянием в git и svn заключалась в следующем: в git было отслеживание слияний, а до версии 1.5 svn - нет.Совсем.Если вы хотите выполнить слияние, вы должны всегда указывать, какие именно изменения должны быть объединены, и если вы объединяете одну ветку в другую более одного раза, вам придется вручную отслеживать, какие ревизии были и не были объединены,и вручную выберите только те изменения, которые еще не были объединены, чтобы избежать конфликтов.Удачи вам в этом, если вы когда-нибудь выберете какие-либо изменения.

Начиная с версии 1.5 (выпущенной в 2008 году), если ваш клиент, сервер и хранилище обновлены, тогда svn способендействовать намного разумнее;он использует свойства для отслеживания того, откуда пришла ветка и какие изменения в нее уже включены.В результате во многих случаях вы можете просто набрать svn merge BRANCHNAME и сделать все правильно.Но из-за своей «болтовой» природы он все еще не очень быстрый и не совсем устойчивый .Git, с другой стороны, имеет для хорошей обработки сценариев слияния из-за своей природы DVCS, и с самого начала он был разработан со структурами данных (такими как используемый DAG) и алгоритмами (такими какrecursive-merge и octopus-merge), которые подходят для этой задачи.

Answer 2

Разница не в том, что вопреки распространенному мнению, из-за распределенной природы DVCS, против централизованной модели Subversion. Ничто не присуще централизованной модели, которая подразумевает, что ветвление и слияние будут некачественными.

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

Answer 3

Не забывайте человеческие компоненты любой системы контроля версий.Ранее сегодня я создал и удалил 3 разных локальных ветки git, потому что это был наименее разрушительный способ решения проблемы в основной ветке.Попробуйте это на централизованном управлении версиями, и вы, скорее всего, получите лекцию от администратора сервера или целую серию гневных писем, если у вас даже есть привилегии делать это вообще.Тот факт, что вы можете иметь филиалы в частном репо, устраняет многие культурные барьеры для эффективного использования филиалов.Алгоритмы, используемые централизованными системами, догоняют DVCS.Эти человеческие факторы останутся.

Answer 4

С Джоэл Хгинит :

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

Когда нам нужно объединиться, Subversion пытается просмотреть обе ревизии - мой измененный код и ваш измененный код - и пытается угадать, как их объединить в один большой безобразный беспорядок.Обычно это дает сбой, создавая страницы и страницы «конфликтов слияния», которые на самом деле не являются конфликтами, просто в тех местах, где Subversion не смогла выяснить, что мы сделали.был занят сохранением серии изменений.И поэтому, когда мы хотим объединить наш код, Mercurial на самом деле имеет гораздо больше информации: он знает, что каждый из нас изменил и может применить эти изменения, а не просто смотрит на конечный продукт и пытается угадать, как его поместить.вместе.

Answer 5

Ветвление или тегирование в SVN - это просто копирование определенного каталога и его подкаталогов в другое место в том же хранилище.В git ветки (и теги) вместо этого описываются как метаданные (во многом как CVS), за исключением того, что они не сбрасывают все эти данные в один файл, а многие (что позволяет выполнять гораздо более быстрые обновления, поскольку вам не нужно переписыватьогромный "foo.c, v" например).Кроме того, git интенсивно использует указатели.(http://eagain.net/articles/git-for-computer-scientists/), так что, на самом деле, мало кто обновляется в первую очередь, когда что-то меняется (например, делается коммит).

Answer 6

Разница заключается в формате хранилища, используемом большинством DVCS - Направленном ацильном графе.

SVN Просто сохранит вашу историю в виде ряда строк, каждая ветвь имеет свою собственную линию. Но DVCS будет хранить его в DAG, которая содержит гораздо лучшую информацию для слияния.