Самая большая разница в том, как имена ветвей записываются в историю. С именованными ветвями имя ветки равно , вложенное в каждый набор изменений и, таким образом, станет неизменной частью истории. С клонами будет нет постоянных запись о том, откуда пришел определенный набор изменений.
Это означает, что клоны отлично подходят для быстрых экспериментов, где вы не хотите записывать название ветки, а названные ветви хороши для длинных ветвей («1.x», «2.x» и т. Д.).
Обратите внимание, что в одном хранилище можно легко разместить несколько светлых ветвей в Mercurial. Такие ветви хранилища можно добавить в закладки, чтобы их можно было легко найти снова. Давайте предположим, что вы клонировали хранилище компании, когда он выглядел следующим образом:
[a] --- [b]
Вы поредактируете и сделать [x] и [y]:
[a] --- [b] --- [x] --- [y]
Mean в то время как кто-то ставит [c] и [d] в хранилище, так когда вы тянете, вы получите диаграмму истории:
[x] --- [y]
/
[a] --- [b] --- [c] --- [d]
Здесь есть две головы в си репозиторий. Ваша рабочая копия всегда будет отображать единый набор изменений, так называемый рабочий набор родительских копий. Проверьте это:
% hg parents
Предположим, что оно сообщает [y]. Вы можете увидеть головы
% hg heads
и это сообщит [y] и [d].Если вы хотите обновить свой репозиторий чистой проверки в [d], а затем просто сделать (заменить [d] с номером версии для [d]):
% hg update --clean [d]
Вы тогда увидите, что hg parents отчет [d]. Это означает, что ваша следующая фиксация будет иметь [d] в качестве родителя. Таким образом, вы можете исправить ошибку, вы заметили, в главной ветви и создать [e] ревизию:
[x] --- [y]
/
[a] --- [b] --- [c] --- [d] --- [e]
Чтобы подтолкнуть [e] только ревизию, что вам нужно сделать
% hg push -r [e]
где [e] набор изменений хэш. По умолчанию hg push будет просто сравнивать репозитории и видеть, что [x], [y] и [e] отсутствуют, но вы, возможно, не захотите разделить и [y].
Если багфикс также влияет, вы хотите, чтобы объединить его с особенностью отрасли:
% hg update [y]
% hg merge
Это оставит свой график репозитария глядя, как это:
[x] --- [y] ----------- [z]
/ /
[a] --- [b] --- [c] --- [d] --- [e]
где [z] является слияние между [y] и [e]. Вы также могли бы выбрать, чтобы бросить ветку в сторону:
% hg strip [x]
Моя главная точка этой истории такова: один клон может легко представить несколько дорожек развития. Это всегда верно для «простого hg» без использования каких-либо расширений. Тем не менее, bookmarks extension. Это позволит вам назначать имена (закладки) для наборов изменений. В приведенном выше примере вам понадобится закладка на голове разработки и одна на головке вверх. Закладки могут быть толкнул и потянул с Mercurial 1.6 и стал встроенной функцией Mercurial 1.8.
Если бы вы решили сделать два клона, ваш клон развития выглядел бы, как это после того, как сделать [x] и [y]:
[a] --- [b] --- [x] --- [y]
И вышестоящий клон будет содержать:
[a] --- [b] --- [c] --- [d]
вас прямо сейчас обратите внимание на ошибку и исправьте ее. Здесь вам не нужно hg update, так как клон вверх готов к использованию.Вы допускаете и создать [e]:
[a] --- [b] --- [c] --- [d] --- [e]
Чтобы включить устранении ошибки в вашем клоне развития вы тянете его там:
[a] --- [b] --- [x] --- [y]
\
[c] --- [d] --- [e]
и слияния:
[a] --- [b] --- [x] --- [y] --- [z]
\ /
[c] --- [d] --- [e]
График Мощь выглядит по-другому, но он имеет ту же структуру, и конечный результат тот же. Используя клоны, вы должны были сделать немного меньше умственной бухгалтерии.
Названные ветви на самом деле не пришли сюда, потому что они довольно необязательны. Сам Mercurial был разработан с использованием двух клонов в течение многих лет, прежде чем мы перешли на использование названных ветвей. Мы также поддерживаем филиал под названием «стабильный» в дополнение к ветке «default» и делаем наши выпуски на основе «стабильной» ветки. См. Страницу standard branching в wiki для описания рекомендуемого рабочего процесса.
если набор изменений пришел от другого пользователя, который был бы записан, поэтому использование клонов ничего плохого. При нажатии новой функции часто неинтересно знать, что вы сделали это из отдельного репо. Существует также расширение localbranch, которое дает вам локальную ветку. Полезно, когда клонирование репо связано с высокими затратами (время/пространство). –
, ссылаясь на: «клоны отлично подходят для быстрых экспериментов» - нет, это не так! Что делать, если у вас есть несколько файлов в репо? Клонирование будет занимать возрасты (в любое время более 1 минуты), а переход филиала - всего лишь один момент (<1 секунда). Все еще использование названных ветвей будет загрязнять журнал изменений. Разве это не тупик? Или я чего-то не хватает? – seler
Okay seler; Звучит как модификация его первоначального аргумента; Клоны хороши там, где накладные расходы на несколько полных копий не важны для вас или когда вы можете использовать символические ссылки/hardlinks hg для уменьшения стоимости отдельных локальных рабочих копий на каждую ветку. –