Как справиться с базаром

Question

Пару раз попали в следующую ситуацию:

1. У меня и другого разработчика есть локальные проверки хранилища.
2. Я делаю некоторые изменения.
3. Другой разработчик вносит и фиксирует некоторые изменения.
4. Я обновляю.
5. Другой разработчик понимает, что их предыдущие изменения были нарушены, и отменяет их.
6. Я обновляю.

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

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

Я пытался выполнить обратное слияние «черриков» на моем кассе между -r -1..-2 и -r 0..-1, но ни один из них не помог. (0..-1 сказал "ничего не делать", хотя я, возможно, не сделал это должным образом. -1..-2 был неправильным набором изменений и тем самым усугубил ситуацию.)

Как я могу исправить эту ситуацию, когда это происходит (кроме как перебраться и ударить другого разработчика головой вверх по голове)?

Answer 1

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

Итак, допустим, вы вручную удалили все его изменения, чтобы у вас остались только ваши. У вас все еще есть ожидание слияния для решения. Вы можете исправить это, набрав

$ bzr revert --forget-merges

Это не изменит ваше рабочее дерево; он только удалит ожидающее слияние с вашего "bzr st", чтобы при фиксации это не выглядело как слияние. Это избавит вас от необходимости сохранять изменения, отменять и повторно применять.

Чтобы этого не случилось снова, вы можете запустить bzr update только непосредственно перед фиксацией. После слияния с bzr commit сразу, и ваши изменения заблокированы. Теперь он не сможет отменить отправку без предварительного обновления и просмотра ваших изменений, и теперь, возможно, ему уже слишком поздно это делать. Если он действительно хочет идти вперед со своим бескомпромиссным поведением, он должен заниматься беспорядком, а не вы.

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

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

------------------------------------------------------------
revno: 34 [merge]
committer: You
branch nick: trunk
timestamp: Fri 2010-11-26 15:57:27 +1100
message:
  Made my changes to the file.
  Note, other guy did some of these changes and uncommitted, but
  I already merged.
    ------------------------------------------------------------
    revno: 33.1.1
    committer: Other Guy
    branch nick: trunk
    timestamp: Fri 2010-11-26 15:39:39 +1100
    message:
      Made some changes to the file.
------------------------------------------------------------

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

Answer 2

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

Answer 3

Это выглядит как bzr pull --overwrite :bound - это то, что вы ищете.