Mercurial - какой смысл в распространении клонов?

Question

На странице Mercurial About написано:

"Традиционные системы управления версиями, такие как Subversion, представляют собой типичные клиент-серверные архитектуры с центральным сервером для хранения ревизий проекта. Напротив, Mercurial действительнораспространяется, предоставляя каждому разработчику локальную копию всей истории разработки. Таким образом, он работает независимо от доступа к сети или центрального сервера. Фиксация, ветвление и объединение выполняются быстро и дешево. "

Так что, когда каждыйРазработчик получает клон от _ (?), тогда каждый разработчик может начать работать над проектом самостоятельно.Спустя 10 месяцев все что-то сделали и изменили RootViewController совершенно по-другому.

Теперь, какой смысл клонировать все это?Когда Dev A меняет RootViewController, Dev B хочет продолжить работу на основе этого изменения.Или нет?Но как Dev B когда-нибудь получит это изменение?Клонируя все это каждый день?Как насчет его собственных изменений?Есть ли какая-нибудь операция супер слияния, которая объединяет все клоны в один большой суперклон, который каждый должен время от времени заменять своим отдельным клоном?

Я уверен, что Mercurial - это круто и полезно.Но я просто не понимаю.

Answer 1

Я нашел основы здесь хорошее введение в Mercurial.

Вы должны начать кое-где. hg init

У всех разработчиков должна быть общая база / предок. hg clone

Они должны получить изменения от других разработчиков / опубликовать свои собственные изменения hg push , hg pull , hg bundle

Вам нужно посмотреть, что поступит в ваш репо, если вы потянули. hg входящий

Какие изменения были сделаны hg diff

Кроме того, удобно иметь несколько центральных хранилищ, где каждый можетнажмите их изменения и вытяните изменения из.

Answer 2

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

Дело в том, что это не все, что вы '

В основном рабочий процесс выглядит следующим образом.

Каждый разработчик клонирует локальный репозиторий и начинает взламывать код.

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

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

Когда они это сделают, у них появятся ветви в своем репозитории впоследствии.

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

т.е.,они заканчивают с чем-то вроде этого, (C) - это общий набор изменений, клонированный всеми:

   o---o---o---o  <-- changes from central repository
  /
(C)
  \
   o---o---o---o  <-- their changes

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

, что приводит к этому:

   o---o---o---o
  /             \
(C)             (M)---o---o---o  <-- continued working after the merge
  \             /
   o---o---o---o

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

Таким образом, вы можете видеть, что:

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

Answer 3

Взято из моего ответа на другой вопрос :

Одна вещь, о которой нужно помнить о DVCS, это то, что на самом деле речь идет не о ее распределенности, а о ветвлении и слиянии. DVCS значительно упрощает ветвление и слияние, так что каждый разработчик / дизайнер / front-ender имеет свою собственную частную ветвь - свое локальное репо. Таким образом, они могут работать параллельно, не наступая друг другу на ноги. Это означает, что они могут проверять код каждые несколько часов, а не ждать дни, пока у них не будет сделано все для его проверки.

Если вы работаете в какой-либо организации (компании, проектной команде и т. Д.), Вам все равно нужен центральный репозиторий, поэтому у вас есть каноническая версия кода. Очень немногие команды используют полностью распределенный рабочий процесс без центрального сервера, потому что по мере увеличения числа людей в вашей команде ваши соединения увеличиваются до N ² , тогда как с центральным сервером он остается равным N *

Answer 4

В распределенной системе контроля версий (DVCS) (mercurial и git) никто не является мастером . (Даже «сервер» - это произвольно выбранный мастер, который больше не имеет права на чужую работу)

Каждый разработчик может сделать свой беспорядок, не заставляя других работать непригодно. Помнишь ли ты в прошлый раз, когда кто-то совершал что-то плохое, и никто не мог работать? Это просто невозможно в DVCS.

В Subversion / CVS вы должны выполнить ветвление, чтобы избежать этих проблем, но объединение является сложным, поэтому это делается редко / не для всех задач.

В DVCS невозможно не разветвляться, но объединение легко и должно быть выполнено после завершения всего кода (ошибка закрыта, завершенная функция, ...). У ваших разработчиков может быть столько веток, сколько у него открытых задач.

Answer 5

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

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

Answer 6

Ответы других людей верны, но я хотел конкретно ответить на ваши вопросы

Теперь, какой смысл клонировать все это?

Теперь у вас есть свой личный репозиторий. Это ускоряет выполнение многих операций, потому что они локальные, но также позволяет вам вносить изменения, которые являются частными, пока вы не захотите поделиться ими.

Удар в результате этого заключается в том, что разработчики могут отделить «регистрацию» от публикации своей работы. Это означает, что вы не получаете большие периоды времени, когда ничего не проверено, потому что «оно не готово к публикации».

Когда Dev A меняет RootViewController, Dev B хочет продолжить работу на основе этого изменения. Или нет? Но как Dev B когда-нибудь получит это изменение?

Когда Dev A рад поделиться своими изменениями , он может либо:

• «подтолкни» его изменения к исходному репо, которое они оба клонировали. Затем Dev B может «вытянуть» их из исходного репо.
• «служить» его репо, так что Dev B может «вытянуть» прямо из него.
• «связать» свои изменения в файл, который можно отправить Деву Б. Затем он может «разложить» их в своем репо.
• ... возможно, некоторые другие методы, которые я забыл.

Клонируя все это каждый день?

Клонирование выполняется только для создания новой копии хранилища. Думайте "svn co".

Обычно вы «вытягиваете» наборы изменений в репозиторий, немного похоже на «svn update»

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

Когда наборы изменений вносятся в репо (например, с помощью 'pull'), они будут существовать в другой ветви. Говорят, что хранилище имеет несколько «голов», которые являются открытыми концами ветвей. Объединяя эти главы, он получит единственную версию, которая содержит изменения из обеих веток. Dev B может продолжить работу над этим. Вы бы получили график, который выглядел примерно так:

До слияния:

     /----o----o Head 'Dev A'
----O Central    
     \----o----o Head 'Dev B'

После слияния:

     /----o----o---
----O Central      \
     \----o----o----o Head 'Dev B'

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

Может быть, Dev A выполняет еще какую-то работу, а затем публикует данные в центральном репо (Примечание: ранее Dev B получал изменения Dev A непосредственно от него. Возможно, B работает над функцией, основанной на коде A, и ему нужна бета-версия кода рано). Вы можете получить график, подобный следующему:

Dev A /----o----o----o----o----o----o----o--\
     /            \              \           \
----O Central      \              \           o--\        /-o
     \              \              \              \      /
Dev B \----o----o----o----o----o----o----o----o----o----o

Dev B сделал несколько снимков кода Dev A во время разработки, и когда Dev A опубликовал свой окончательный код в центральном хранилище, Dev B смог получить дополнительные изменения, объединиться с ними и вытолкнуть все свои возвращается к центральному репо тоже. Поскольку Mercurial знал о снимках кода B, которые имелся в коде А, он не запутался, когда вытащил из центрального репо. Он просто сказал: «О, я уже кое-что получил».

Итак, для меня две убийственные функции DVCS:

• Регистрация больше не означает публикацию.
• Разработчики могут делиться кодом контролируемым образом, не проходя через центральное хранилище и, следовательно, публикуя.

Ух ты, это долго, но надеюсь, это поможет.