Коротко : Как я могу взять последнюю версию (только) из удаленного базарного репозитория и добавить ее в качестве новой ревизии в локальный репозиторий.
Предпосылки : У меня есть система разработки и производственная система. В системе разработки есть репозиторий базаров, имеющий ветку с большим количеством ревизий разработки. Время от времени я хочу включить последние разработки в производственную систему. Я хочу сделать это с помощью некоторого «вытягивания» (система разработки не может подключиться к производству по соображениям безопасности, но производство может инициировать подключение к разработке).
Что касается производства, мне не нужна вся история изменений разработки, а только те изменения, которые фактически поступают в производство (обычно это ветвь подсказки). Тем не менее, я хочу, чтобы контроль версий в производственной системе каждый раз отслеживал, что на самом деле идет в производство.
bzr pull
тянет всю ветвь. bzr pull --revision=last:1
также тянет всю ветку, вплоть до указанной ревизии.
bzr merge --pull --revision=last:1
также тянет всю ветвь. bzr merge --pull --revision=last:2..last:1
и bzr merge --pull --change=last:1
оба извлекают только новые изменения , введенные в последней ревизии, но не изменения, внесенные в более старые ревизии.
С облегченной проверкой у меня нет отслеживания ревизий, которые вводятся в производство - локальное рабочее дерево остается частью удаленного репозитория. и отправляя их в местное отделение впоследствии. Есть идеи получше?
В некоторой степени вы можете сделать это, запустив:
$ bzr branch --stacked REMOTE-URL LOCAL-PATH
это создаст локальную ветку, которая имеет только несколько последних ревизий. Это независимая ветвь, поэтому, если вы делаете коммит в локальной ветке, он не будет автоматически перенесен в удаленную ветку. Если вы попытаетесь получить доступ к каким-либо данным в локальной ветке, которые недоступны, bzr отправит их в удаленную ветку, чтобы найти эти данные.
Прежде всего, вы не можете сделать это, просто потянув IMO последней ревизии, потому что каждая ревизия хранит только различия с предыдущей ревизией. Это объясняет, почему, например, bzr merge --pull --change=last:1
не работает.
Я бы ДЕЙСТВИТЕЛЬНО просто потянул всю ветку, но если вы не хотите этого, вы можете сделать что-то вроде
bzr diff -rx -p1
, где x
- последняя ревизия, которую вы уже включили в производство. Это создает обзор всех изменений между текущим рабочим каталогом и ревизией x
, но без всех деталей ревизий между ними. Флаг -p1
обеспечивает вывод в формате патча ( http://doc.bazaar.canonical.com/beta/en/user-reference/diff-help.html ). Затем вы можете применить этот патч в вашей производственной системе.
Я думаю, что это некрасиво, но это может сделать работу.
Если я правильно понимаю, вы хотите синхронизировать производственную ветвь с тем же состоянием, что и у подсказки ветки разработки, но без истории изменений, верно?
Вы можете сделать это с помощью:
bzr merge OTHER_URL
bzr revert --forget-merges
bzr commit
Результат фактически такой, как если бы вы выбрали вишни для изменений всех отсутствующих ревизий и зафиксировали их все сразу.
Однако здесь есть ОГРОМНОЕ предостережение. Поскольку история изменений не сохранилась, Bazaar не знает, что изменения, которые вы выбрали, уже применены. Следствием этого является то, что в следующий раз, когда вы попробуете эти же шаги, вы получите конфликты. Поэтому я не думаю, что это полезное решение.
Другой способ (с другой оговоркой) заключается в следующем:
bzr diff --new OTHER_URL | patch -p0
Это будет применять diff текущей ветви и эталонной ветви как патч. Предупреждение: патч не может обрабатывать переименования.
В целом, я думаю, что вы пытаетесь сделать это странно. Вы должны просто вытащить или объединить и сохранить историю. Или вы можете попробовать работать с функциональными ветками. Особенность ветвей функций заключается в том, что после завершения функции вы перестаете работать с ней. В этом случае вы можете объединить всю ветвь компонента и забыть о промежуточных ревизиях, потому что вы никогда больше не будете сливаться из ветви компонентов, поэтому у вас не возникнет проблема двойного выбора вишни.