2012-02-27 4 views
2

Gerrit объединит потенциально незаметные изменения, которые ранее были в истории фиксации и находятся в другой «ветке» репозитория. Вот пример:Есть ли способ заставить Gerrit, чтобы все фиксации в ветке были нажимать на просмотр кода?

  1. контроль Геррит филиал devel
  2. создать FILE1.TXT, добавить, фиксации, нажмите на refs/heads/temp_branch
  3. создать file2.txt, добавить, фиксации, нажмите на refs/for/devel быть код рассмотрен

Когда файл2.txt принимается и объединяется, то file1.txt, потому что он находится вверх по течению, а не в отдельной ветке изменений, помеченной как находящаяся под контролем, также объединяется. Это потенциально очень проблематично и единственное решение, с чтобы каждое изменение, которое было перенесено в каждую ветвь, проверялось кодом. Это не идеально, поскольку вы можете захотеть иметь какие-либо ветви с одной группой утверждающих или без проверки кода (для некоторой замены кода?).

Решение состоит в том, чтобы заставить каждое фиксацию в истории быть помещено в обзор кода, как если бы файл file1.txt не был перенесен в другую ветку в том же репозитории.

Есть ли настройка в Gerrit, которая налагает это правило? Может ли кто-нибудь подумать о рабочем процессе, который позволяет свободе нажать на refs/heads/, не рискуя загрязнить другие ветви?

Большое спасибо.

+0

Я думаю, что в вашем примере шаг 2 действительно является толчком к refs/for/temp_branch? – Brad

ответ

2

Я подозреваю, что вы видите это поведение, потому что фиксация на шаге 3 имеет фиксацию шага 2 в качестве родителя. Вы не можете отправить коммит, если все его родители не были отправлены. Я согласен с вами в том, что это похоже на ошибку в Gerrit - она ​​должна отказаться от представления до тех пор, пока не будет представлен второй шаг.

Попробуйте эту работу вокруг - добавить шаг 2а после шага 2:

2а. снова проверить ветвь devel

Если коммиты собираются в 2 разных ветвях, для них не имеет смысла быть линейными.

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

+0

Оказывается, этот недостаток был отмечен на сайте [Gerrit] (http://code.google.com/p/gerrit/issues/detail?id=1107&sort=priority&colspec=ID%20Type%20Stars%20Milestone%20Status% 20Priority% 20Owner% 20Summary). Хотя ты был прав насчет вишни! Я не уверен, доверяю ли я вишневым выборам с точки зрения конфликтов слияния, которые могут возникнуть в результате чересстрочных изменений, проходящих через проверку кода, и, как правило, сохранение целостности истории фиксации. Но он действительно сталкивается с проблемой непреднамеренного слияния непредвиденных изменений. – mut1na

+0

только для добавления, вишневый выбор по существу делает фиксацию в начале координат «официальным» идентификатором фиксации, когда он объединяется. Также это означает, что вам нужно переустановить свою ветвь происхождения для своих собственных изменений (хотя это будет тривиально т.е. нет конфликтов, поскольку у вас уже есть код!), поэтому ваша ветка не расходится с происхождением. – mut1na