Размышления пользователя Subversion: что такое «ветвь» в терминах Mercurial?

Question

Я - пользователь Subversion, и я думаю, что теперь я в основном разбираюсь в этом. Поэтому, конечно, сейчас мы думаем о переходе на Mercurial, и мне нужно начать заново.

В нашем единственном репозитории мы имеем типичный макет branches, tags, trunk. Когда я хочу создать ветвь функции I:

• Используйте браузер репо для копирования trunk в branches/Features/[FeatureName].
• Оформить новую рабочую копию из branches/Features/[FeatureName].
• Начните работать над этим.
• Изредка коммит, объединение trunk в, разрешение конфликтов и коммит.
• По завершении, еще одно слияние trunk, затем «Реинтеграция» ветви объекта в транк.

(Обратите внимание, что этот процесс упрощен, поскольку он не учитывает ветки-кандидаты на выпуск и т. Д.).

Таким образом, у меня есть вопросы о том, как бы я соответствовал тем же требованиям (т. Е. Функциональным ветвям, а не по магистрали) в Mercurial:

• В Mercurial ветвь все еще находится в репозитории, или это совершенно новый локальный репозиторий?
• Если у каждого из нас есть копия всего хранилища, означает ли это, что у всех нас есть копии различных ветвей функций друг друга (это большая передача данных)?
• Я знаю, что Mercurial является DCVS, но означает ли это, что мы передаем / извлекаем изменения друг от друга напрямую, а не через одноранговое хранилище на сервере?

Answer 1

Я рекомендую прочитать это руководство http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial//

Answer 2

В Mercurial ветвь все еще находится внутри хранилище, или это совершенно новый локальный репозиторий?

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

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

Да, если вы посмотрите историю заголовка вашего локального репозитория, то сможете увидеть все ветви функций, которые были объединены. Но ртутные репозитории удивительно экономят место. Например, я сделал hg clone https://www.mercurial-scm.org/repo/hg, чтобы получить исходный код самого mercurial, и он составляет всего 34,3 МБ в файловой системе NTFS (по сравнению с загрузкой исходного кода , что составляет 1,8 МБ). Mercurial также будет использовать жесткие ссылки, если ваша файловая система его поддерживает, поэтому при клонировании репозитория в другое место на том же диске будет мало накладных расходов.

Я знаю, что Mercurial является DCVS, но делает это означает, что мы выталкиваем / вытягиваем изменения друг друга напрямую, а не через одноранговый репозиторий на сервере?

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

Однако обычно у вас есть один или несколько «благословенных» репозиториев, в которые интегрированы все изменения. Всех разработчиков тогда нужно только вытащить из благословенного репозитория. Даже если бы у вас не было такого благословенного хранилища, я думаю, что люди автоматически организуются таким образом, например. все тянет от ведущего разработчика.

Answer 3

Статья Стива Лоша о ветвлении в Mercurial, связанная выше, фантастическая. Я также получил некоторые объяснения ветвления и того, как DAG работает в презентации, которую я дал пару месяцев назад на тему mercurial, которая отсутствует на slideshare . Соответствующие слайды начинаются со слайда № 43.

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

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

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