Различия между версиями SVN и GIT

Question

Я хотел бы знать, в чем разница между версиями, предлагаемыми git (или другими DVCS) и subversion (или другими CVCS).

Вот что я нашел на http://www.xsteve.at/prg/vc_svn/svn.txt по этой теме:

Subversion управляет версионными деревьями как объектами первого порядка ( хранилище - это массив деревьев), а наборы изменений - это то, что получены (путем сравнения соседних деревьев.) Системы, такие как Arch или Bitkeeper построены наоборот: они предназначены для управления наборы изменений в качестве объектов первого порядка (хранилище представляет собой пакет патчи), и деревья получены путем составления наборов патчей вместе.

Но не ясно, как в хранилище Subversion хранятся изменения, содержит ли он самый старый вариант версионного файла и так далее. Почему мы не можем сгенерировать кучу патчей, как, например, в случае с git? Это всегда упоминается как принципиальное различие между svn и git, которое упрощает / усложняет слияния, но, к сожалению, я все еще не понимаю эту идею.

Answer 1

Хорошее объяснение основных различий между VCS на основе наборов изменений и снимков см. В Блог Мартина .Я не буду повторять это здесь.

Однако я бы подчеркнул один момент, который может быть неочевидным на первый взгляд.VCS на основе наборов изменений позволяют действительно легко отслеживать слияния, что намного сложнее для систем, подобных Subversion, основанной на моментальных снимках.

В VCS на основе наборов изменений слияния - это просто наборы изменений (или коммиты, поскольку они 'Вызывается в git), которые имеют более одного родительского набора изменений.Графическое представление хранилища обычно показывает DAG (Направленный ациклический граф), где узлы представляют наборы изменений, а стрелки представляют отношения родитель-потомок.Когда вы видите узел с более чем одним родителем, вы точно знаете, какой тип слияния произошел там.

В Subversion «отслеживание слияния» является чем-то новым.До версии 1.4 такого понятия не было, поэтому для того, чтобы узнать историю слияний, вы должны были делать записи в журнале сообщений ваших коммитов.В версии 1.5 реализовано отслеживание слияний, чтобы упростить выполнение повторных слияний из одной ветви в другую, не заставляя пользователя четко указывать диапазоны ревизий и тому подобное.Это реализуется с помощью свойства (svn: mergeinfo), связанного с каталогом, получающим слияние.Он отслеживает, какие ревизии уже были объединены, из каких веток.Этого достаточно, чтобы определить, какие ревизии следует объединить в последующие слияния.Но это не облегчает рисование графиков, показывающих историю слияний, которую вы часто хотели бы видеть, работая над сложным проектом с несколькими разработчиками.

Answer 2

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

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

Так что на самом деле, хотя патчи кажутся повсеместными в пользовательских интерфейсах git, на самом деле они не имеют никакого отношения к тому, как хранятся данные - дельты, которые хранятся в файлах пакетов, являются дельтами двоичного уровня, а не текстовым отличается вообще. Git будет применять дельты для получения объектов, а затем снова разграничивать их для создания патча по требованию. Это, в отличие от, например, CVS, который унаследовал систему хранения последней версии плюс обратные дельты от RCS.

Судя по тому, что вы цитировали, кажется, что Git и SVN на самом деле более похожи, чем любой из них, например, на CVS.

Answer 3

Поздний и частичный ответ. Я не думаю, что следующее было разъяснено выше:

Важные условия:

CVCS = C Entralized Version Control System
DVCS = D Система контроля версий (используется Git)

REPOSITORY = Дерево файлов проекта, т. Е. Каталог с одним или несколькими подкаталогами, со всеми многими файлами для одного проекта. Например:

./Project1/README
./Project1/myprogram.c
./Project1/Makefile
./Project1/images/1.gif
./Project1/images/2.gif

---

Централизованная:

Один (централизованный) репозиторий, доступный всем.

Использование:

• Пользователь извлекает файл, который он хочет отредактировать (т.е. получает копию этого файла из удаленного хранилища),
• Они редактируют файл локально на своем компьютере, а затем
• Они проверяют файл обратно в центральное хранилище (т.е. копируют его обратно в центральное хранилище, которое записывает изменения и делает изменения доступными теперь для других пользователей).

Разрешение на внесение изменений предоставляется всем пользователям.

Распространяется:

Один репозиторий только для чтения, общий для всех, , а затем как минимум полная копия этого репозитория в местоположении каждого пользователя.

Другими словами, каждый пользователь создает копию всего дерева проекта на своем локальном компьютере или копирует все дерево файлов из основного хранилища.

Использование:

• После локального редактирования пользователем
• Затем они могут отправить редактирование обратно в центральный репозиторий, чтобы оно могло быть включено и, таким образом, передано другим.

Разрешение на внесение изменений контролируется владельцем проекта, который контролирует основной репозиторий. (В git у нас есть «запрос на извлечение» или запрос к владельцу проекта, который контролирует центральный репозиторий, внести новые изменения.)

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

Ссылка: Эта является хорошей более полной статьей.