Как DVCS облегчает проблемы с прямой проверкой транка, когда вы пытаетесь объединиться обратно в транк?

Question

Мы используем SVN, где я работаю.Большая часть работы выполняется в транке, но некоторые люди предпочитают тянуть ветки, чтобы работать с большими, разрушительными функциями.У нас есть соглашение, согласно которому мы объявляем, что транк заблокирован, когда мы объединяем ветку обратно в транк.Смысл этого состоит в том, чтобы предотвратить прямые коммиты по транку, пока происходит слияние, что требует еще одного слияния до совершения слияния обратно в транк.,(Или, возможно, они просто придурки. Что угодно.) Мы говорили об использовании DVCS, который, вероятно, решит эту проблему (кажется, что это присуще понятию «распределено»), но без опыта работы с ними я не вижуhow.

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

Answer 1

Единственное реальное надежное решение этой проблемы - это использование модели «привратника», как человеческой, так и автоматической.

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

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

Подробнее об идее привратников вы можете прочитать в документации bzr: http://doc.bazaar.canonical.com/bzr.2.4/en/user-guide/using_gatekeepers.html

Answer 2

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

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

Это действительно сильное преимущество DVCS.Работа слияния не потеряна.После того, как вы объединили набор изменений, вам не нужно делать это снова.

Модель GitHub

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

http://help.github.com/send-pull-requests/

Answer 3

Поскольку DVCS предполагает, что работа будет выполняться в различных репозиториях, а затем объединяться, слияния будут умнее, чем слияния Subversion - ваш цикл извлечения / слияния / построения будет быстрее и менее болезненным.

Но, честно говоря, это больше похоже на проблему людей / процессов, чем технологических проблем. Связь поможет больше, чем переключение VCS.

Answer 4

Преимущества, которые может иметь mercurial, тройные.

1. Вы можете добавить дополнительную головку в центральное хранилище, если вы действительно этого хотите (но, вероятно, это плохая идея).В Subversion нет понятия «головы», поэтому вы не можете этого сделать.

2. Вы можете выполнять итеративное слияние + фиксация.Итак, вы бы вытащили последнюю голову из хранилища "багажник".Вы бы слились в ваших изменениях.Вы бы сделали это локально.Затем вы извлекаете любые дополнительные изменения из ствола и объединяете их как новый набор изменений поверх предыдущего набора изменений слияния.С Subversion вы не можете этого сделать - вы должны продолжать пытаться выполнить слияние за 1 попадание.

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

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

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