Mercurial + hgsubversion + svn: рассказ о двух репозиториях (или заменить наборы изменений?)

Сценарий:

У меня есть 2 репозитория Hg: один, который отслеживает репозиторий SVN, скажем SVN-track, и локальный репозиторий pure-Hg, в который я загружаю ревизии из первого.

Я помещаю наборы изменений из репозитория pure-Hg в репозиторий SVN-track, а затем перемещаю изменения в репозиторий SVN-track до тех пор, пока история хороша и прямолинейна, поэтому я могу перейти в репозиторий SVN.

После того, как я нажимаю на SVN, hgsubversion извлекает набор изменений из SVN и удаляет исходный набор изменений. Я так понимаю, он отслеживает (но ... почему бы просто не сохранить оригинал и не отслеживать его?).

Проблема:

Теперь, если вы так долго зависали, возникает проблема: я хочу вернуть наборы изменений SVN в репозиторий pure-Hg, но все исходные наборы изменений возвращаются как дубликаты (но с другим узлом ids) на другой голове. Я мог бы перенастроить все ревизии, которые я добавил в репозиторий pure-Hg, но тогда я потеряю историю, и, действительно, это кажется слишком большим трудом. Я мог бы просто жить с ревизиями вытянутого SVN с дублированным контентом и объединять локально, но это делает результирующие отталкивания обратно на SVN-track все труднее и труднее.

Вопросы:

  • Есть ли лучший способ выполнить этот рабочий процесс, о котором я не могу догадаться без посторонней помощи?
  • Если нет, как мне заменить исходные ревизии, которые hgsubversion извлекает из SVN, в pure-Hg?
  • Почему hgsubversion (по большей части замечательный инструмент для включения) должен возвращать наборы изменений SVN только для их отслеживания, не может ли он просто сохранить исходный набор изменений и добавить строку в .hg/svn/rev_map, указывающую исходный идентификатор набора изменений?
  • Если да, то какой в ​​этом трюк?

version-control svn mercurial hgsubversion
person codekaizen    schedule 30.11.2011    source источник
comment
Какова цель репо чистой ртути? Обычный рабочий процесс с подключением Hg к SVN - это делать то же, что и в репозитории SVN-track. Внесите изменения, извлеките из SVN, переустановите, нажмите на SVN.   -  person Steve Kaye    schedule 01.12.2011
comment
Репозиторий чистой Hg предназначен для того, чтобы иметь возможность жить в мире Hg, где у меня может быть полная история, несколько веток, закладки и т. Д. Я все больше и больше недоволен нормальным рабочим процессом, чем больше я узнавал, чего мне не хватало. .   -  person codekaizen    schedule 01.12.2011
comment
К сожалению, я не думаю, что это возможно при работе с Subversion. Вам необходимо выполнить переустановку, чтобы история перешла в состояние, которое она может понять, а перебазирование должно выполняться только тогда, когда вы знаете, что история, которую вы изменяете, никуда не делась. В вашем случае вы знаете с точностью до наоборот. Репозиторий с чистой ртутью имеет исходную историю, поэтому вытягивание / толкание между ними всегда будет вызывать проблемы.   -  person Steve Kaye    schedule 01.12.2011
comment
Но почему мне (через hgsubversion) нужно откатить от SVN наборы изменений, которые я нажимаю? Поскольку это атомарные коммиты, почему я не могу просто предположить, что они будут одинаковыми, и просто сопоставить наборы изменений, которые я отправляю в SVN, с ревизией SVN, не вытаскивая и не удаляя оригиналы?   -  person codekaizen    schedule 01.12.2011
comment
Это не часть hgsubversion, которая не работает - она ​​просто получает новые изменения должным образом. Дело в том, что у вас есть два связанных репозитория Hg и вы изменяете историю в одном, а не в другом. Это общепринятый запрет всех DVCS (насколько мне известно)   -  person Steve Kaye    schedule 01.12.2011
comment
Это простая часть - я могу использовать hg graft. Проблема на самом деле заключается в обманутых ревизиях из hgsubversion.   -  person codekaizen    schedule 01.12.2011
comment
позвольте нам продолжить обсуждение в чате   -  person Steve Kaye    schedule 01.12.2011

Ответы (1)


arrow_upward
0
arrow_downward

Причина, по которой hgsubversion должна отозвать изменения, (я полагаю), потому что могли быть другие изменения в svn до того, как вы сделали свой push. Каждый коммит в svn включает «rebase-to-tip», который может повлиять на ваш набор изменений. Следовательно, ему нужно вернуть его, чтобы получить то, что на самом деле произошло, и новые идентификаторы набора изменений.

Perfarce (расширение perforce) делает нечто подобное, но объединяет исходные изменения с новой подсказкой, так что график действительно имеет смысл. Тем не менее, все еще есть дубликаты всех внесенных мною изменений.

person Paul S    schedule 01.12.2011
comment
Если раньше в SVN были другие изменения, SVN не разрешит push / commit. Он будет жаловаться на то, что файл '/home/sally/svn-work/sandwich.txt' устарел - person OK.; 01.12.2011
comment
Но почему не просто тянуть-перебазировать? Конечно, есть и другие ревизии, но hgsubversion все равно заставляет меня тянуть и перебазировать, почему бы просто не сказать, что ревизии, которые я нажимаю, а затем существующие в SVN, являются теми наборами изменений, которые у меня есть? - person codekaizen; 01.12.2011