Как вы выяснили, основное ограничение HgSubversion заключается в том, что вам нужно линеаризовать историю Mercurial при ее перемещении в Subversion. Это означает, что вы не можете иметь ветки в своей истории Mercurial, и поэтому трудно работать вместе как одна команда.
Кроме того, HgSubversion сделает ребаз , когда вы нажмете свои ревизии Mercurial. Представьте, что ваша команда старается перебазировать свои локальные коммиты, прежде чем отправлять на сервер Mercurial. История Меркурия выглядит так:
... r10 --- a1 --- a2 --- b1 --- b2 --- b3
, где Алиса и Боб перебазировали свои наборы изменений, прежде чем их подтолкнуть. При синхронизации с Subversion вы получаете:
... r10 --- a1 --- a2 --- b1 --- b2 --- b3
\
r11 --- r12
и HgSubversion теперь будут перебазировать наборы изменений Mercurial поверх [r12]:
... r10 --- r11 --- r12 --- a1' --- a2' --- b1' --- b2' --- b3'
Алиса и Боб по-прежнему имеют исходные необновленные наборы изменений без простых чисел. Поэтому им нужно раздеться, прежде чем они извлекут из команды Mercurial сервер. Такой рабочий процесс требует большой осторожности.
Я однажды настроил более простой рабочий процесс для клиента: вместо того, чтобы перебирать наборы Mercurial поверх ревизий Subversion, мы просто передали текущую версию файлов в Subversion. Это означает, что мы не сохраняем полную историю Mercurial в хранилище Subversion. С другой стороны, мы можем легко справляться со слияниями и так далее.
В приведенном выше примере сервер SVN получит r13 с состоянием хранилища Mercurial из b3. Эта ревизия r13 будет большой: она содержит все изменения, сделанные от a1 до b3. Если люди, которые все еще используют Subversion, хотят увидеть отдельные изменения, им придется посмотреть на сервере Mercurial - сообщение о фиксации, которое мы помещаем в Subversion, содержит ссылки на отдельные наборы изменений в hgweb для Mercurial, так что легко прыгать туда.