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

Ответ 1

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

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

Ответ 2

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

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

Ответ 3

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

Ответ 4

Из Joel hginit:

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

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

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

Ответ 5

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

Ответ 6

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

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