Поскольку ваш «восходящий» репозиторий - Subversion, вы можете использовать комбинацию Mercurial Queues , Rebase и Convert расширений для отслеживания локальных измененийСложены поверх исходного источника.
Общая идея заключается в том, что вы можете выбрать ветку Subversion из репозитория "upstream" и использовать расширение Convert для генерации локального клона Mercurial систория конкретной ветки, например:
________
(________)
| | Subversion repository
(________)
|
| hg convert svn+ssh://host/repo/branch svn-branch
|
v
.------------------.
| |
| svn-branch/.hg |
| |
`------------------'
Расширение convert может также в будущем извлекать наборы изменений из Subversion, так что вы можете настроить задачу cron, которая обновляетваша локальная «чистая» копия вышестоящего кода.
Затем вы можете создать столько локальных клонов, сколько захотите, из svn-branch, например:
________
(________)
| | Subversion repository
(________)
|
| hg convert svn+ssh://host/repo/branch svn-branch
|
|
| .-------------.
| .-----> | feature-1 |
v | `-------------'
.------------------. |
| | clone | .-------------.
| svn-branch/.hg | -----------+-----> | feature-2 |
| | | `-------------'
`------------------' |
| .-------------.
+-----> | bugfix-1 |
`-------------'
После настройки локальногоклоны, у вас есть две опции для ваших собственных патчей:
- Зафиксируйте свои собственные изменения в виде ртутных наборов изменений в feature-1 , feature-2 или bugfix-1 и продолжайте «сливаться» с вышестоящим клоном svn-branch
- Сохраняйте свои собственные изменения в feature-1 и т. д. как исправления MQ и перебазируйте их каждый раз, когдавышестоящий набор наборов изменений отображается в локальном зеркале
svn-branch.
Оба подхода имеют свои плюсы и минусы.
Локальные изменения с использованием «нормальных» наборов изменений
ЕслиВаше намерение состоит в том, чтобы просто сохранить локальную функцию, и вы на самом деле не заботитесь об отправке «чистого исправления» разработчикам из основной ветки разработки, тогда периодические прогоны hg pull и hg merge идеальны.Повторные слияния будут легкими.Конфликты будут минимальными.Вы можете отслеживать, когда, кто, что было объединено и почему.Что еще более важно: вы можете поделиться и опубликовать ваш локально модифицированный клон с другими.И т. Д.
С локальным репозиторием svn-branch/.hg, который имеет в основном линейную историю Subversion, повторные слияния будут выглядеть следующим образом (наборы изменений в скобках - это коммиты "только для локальных систем"):
[0] --- [1] --- [2] --- [4] --- [5] --- [7] --- [8] --- [9] --- [10]
\ \ \
`-- (3) ------- (6) -------------------------- (11)
Локальные изменения в changeset (3) не видны вышестоящим людям Subversion, но вы можете увидеть в локальной истории, что они были объединены дважды с вышестоящим кодом: в commitits (6) и(11).Поскольку каждое объединение записывается как нормальный набор изменений в Mercurial, легко увидеть, кто произвел объединение, когда, что было объединено и т. Д. Также очень легко проверить, какие локальные изменения есть в любой точке объединения, например, запустив:
hg diff -r 5:6
hg diff -r 10:11
Вы даже можете записать локальные наборы изменений в с именем ветвь, например, зафиксировав изменения (3) с помощью:
hg branch feature-1
hg commit -m "Message"
Затем просматривая различияиз «вышестоящего» кода поставщика можно использовать название ветви:
hg diff -r default:feature-1
Вам решать, как вы будете отслеживать локальные слияния и сколько локальной информации вы хотите хранить.
Локальные изменения с Mercurial Queues
Если вы разрабатываете локальное исправление «в изоляции» и планируете отправить исправление в виде «чистого различий» разработчикам Subversion восходящего направления, тогда MercurialQueues в сочетании с расширением Rebase позволяют легко хранить ваши патчи "поверх" локального зеркала SVN.Весь процесс перебазирования ваших локальных исправлений часто так прост:
# Incrementally pull changesets from the upstream Subversion
# repository into a local hg clone:
cd ~/work/svn-branch
hg convert svn+ssh://host/repo/branch .
# Rebase the local patches of 'feature-1' on top of the
# latest subversion commits:
cd ~/work/feature-1
hg qpush -a && hg pull --rebase
Создание локальной "очереди исправлений" в одном из клонов вашего зеркала svn-branch является первым шагом:
cd ~/work/feature-1
hg qinit -c
Затем вы можете внести свои локальные изменения и сохранить их как патч MQ:
emacs src/foo.c
hg qnew --git --force --edit
Вы можете создать столько локальных патчей, сколько захотите, поверх исходных коммитов svn-branch.Например, мое локальное «головное» зеркало FreeBSD теперь включает следующие патчи:
keramida@kobe:/hg/bsd/src$ hg qseries -s
newvers-hg-support: Include the hg changeset number to uname output too.
kernconf-kobe: Add a kernel config file for my laptop, based on GENERIC
truss-style: Style nits for lines that are too long after recent truss changes.
yacc-core-dump: Fix a yacc(1) core dump reported by darrenr; patch by ru
loader-prompt: Lowercase the "OK" prompt of the boot-loader
top-rawcpu: Make top(1) use raw (non-weighted) cpu mode by default, like ps(1)
nogames-mtree: Fix `make installworld' when WITHOUT_GAMES=yes.
typo-fixes: Fix misc typos in source code comments & docs
mg-00-import: Import a snapshot of the mg(1) editor from OpenBSD
mg-01-freebsd-changes: Adapt the OpenBSD code of mg(1) to FreeBSD's environment
mg-02-build: Attach the mg(1) editor to the FreeBSD build process
regression-chmod: Add a few regression tests for chmod(1)
regression-stdtime: Add a regression suite for libc/stdtime functions
keramida@kobe:/hg/bsd/src$
Конечно, можно хранить локальный стек из сотен изменений. MQ довольно удобен для локальной разработки патчей, их тонкой настройки, разделения или объединения в более крупные наборы патчей, а в сочетании с расширением Rebase это мощный способ поддерживать работу локального набора патчей в движении. вдоль истории вверх по течению.
Эквивалентная история изменений для патча changeset (3) из предыдущего примера будет выглядеть примерно так:
# History snapshot #1 - the local changes in (3) as an
# MQ patch P1 on top of changeset [2] from svn-branch:
[0] --- [1] --- [2] --- (P1)
Затем, когда вы добавите еще несколько подрывных коммитов в клон svn-branch, вы сможете перебазировать локальный патч P1 поверх последнего кода SVN:
# History snapshot #2 - patch P1 rebased from [2] to the
# latest svn-base commit:
[0] --- [1] --- [2] --- [3] --- [4] --- (P1')
.
. (P1) . . hg rebase . ^
Через несколько дней вы конвертируете больше изменений из Subversion в svn-branch и еще раз перебазируете:
# History snapshot #3 - patch P1' rebased from [4] to the
# latest svn-base commit, as a possibly very modified
# version, shown as patch P1'':
[0] --- [1] --- [2] --- [3] --- [4] --- [5] --- [6] --- [7] --- [8] --- (P1'')
.
. (P1) . . . . hg rebase. . . . . . . . ^
Вы можете продолжать перебазировать свой локальный патч столько раз, сколько возможно. Вы можете даже перебазировать несколько патчей в каждой итерации. Вы можете вставить патчи в «середину» очереди с несколькими патчами. Вы можете удалить патчи. Вы можете присоединиться к различиям, разделить их на большее количество патчей, изменить порядок расположения патчей. В общем, вы можете переписывать и настраивать очередь исправлений столько раз и сколько захотите.