Что разветвлено в репозитории?

Question

Из того, что я понимаю в Subversion, если у вас есть репо, содержащее несколько проектов, то вы можете разветвлять отдельные проекты в этом репо (см. Красная книга SVN - Использование веток )

Однако я не совсем понимаю, что происходит, когда вы создаете ветку в одной из распределенных систем (Git, Hg, Bazaar - я не думаю, что это важно). Вы можете разветвлять только подкаталог репо, или когда вы создаете ветку, вы разветвляете весь репо?

Этот вопрос является частью более крупного вопроса, который я разместил в superuser ( выбор и настройка управления версиями ), и возник, когда я пытаюсь выяснить, как лучше всего управлять версиями большой иерархической структуры независимых проектов.

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

Answer 1

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

Базар не имеет подпроектов. Ветвь - это единое целое. Вы не можете разветвлять его части. Я полагаю, что у git и hg есть дочерние ветви.

Answer 2

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

• изоляция истории (которая является основным назначением ветви : вы изолируете версии набора файлов от других версий из того же набора файлы)
• «компонентная» изоляция (компонент или модуль представляет собой группу файлов, каждый из которых находится в своем собственном каталоге)

Но с DVCS каждый репозиторий является собственным компонентом (или модулем).
То есть Вы не хотите помещать все своих проектов в один репозиторий.
Скорее вы используете подмодулей (Git) или подпунктов (Hg) .

Это оставляет вас с ветвью как чисто историческую изоляцию:
Когда вы ветвитесь, история репо all создает новую ветку, готовую записывать (ссылаться) на любой новый коммит, который вы сделаете.
Это не «дешевая копия», просто сделан новый указатель.
Примечание: Mercurial имеет более сложную модель ветвления , которая может включать клонирование репо для создания новой ветки, но общий принцип стоит за ветвлением.

Answer 3

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

- o - o - o - o - o (branchA)
           \
            o - o (branchB)

Каждый o имеет коммит, который представляет состояние всего хранилища на данный момент. Таким образом, две ветви в общем представляют разные состояния всего репо, хотя может случиться так, что они различаются только содержимым одного подкаталога. Там, конечно, не будет пустого места; если два коммита используют одну и ту же версию данного файла, они внутренне указывают на один и тот же объект для его содержимого.

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

Answer 4

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

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

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