Я объясню мою проблему,
В настоящее время я использую внутреннюю установку gitious с использованием git. Я хотел бы начать тестирование FogBugz и Kiln из Fog Creek, которые используют Mercurial. Я хотел бы хотя бы ненадолго продолжить разработку с использованием обоих решений.
Кто-нибудь знает о каких-либо серьезных долгосрочных последствиях использования мерзавца и репозитория в одном каталоге? Или есть лучший способ синхронизации сервера git и mercurial.
Я попробовал это с тестовым репо, и я не видел никаких проблем.
Спасибо за любую помощь.
.svnфайлов SVN .Ответы:
Я обнаружил, что мост hg-git вполне пригоден для использования в другом направлении (некоторые материалы на Github, изначально построенные с использованием Mercurial для управления исходным кодом). По сути, вы «просто» используете mercurial, создаете закладку, связывающую «master» с «default», когда вы готовы перейти к git-репо, и push. Pull from git работает так же, как и при удаленном репо. В этом сценарии вы не получите файлы .git + .hg, у вас есть только ртутные файлы на вашем локальном компьютере, если только вы не перешли на git полностью, и в этом случае вы, вероятно, сделаете git clone в новом каталог.
Есть аналогичный проект для пользователей git, которые хотят выгружать / извлекать из репозиториев Mercurial, но у меня нет прямого опыта с этим. Смотрите https://github.com/offbytwo/git-hg.
Кроме возможности случайной проверки множества скрытых папок из вашей «другой» системы контроля версий, я не вижу реальной проблемы с выполнением hg init в репозитории git; мне просто кажется менее неуклюжим использовать мост и явно выбирать, когда передавать в другую систему dvcs.
источник
Я использовал и mercurial, и git в одном проекте, в одном рабочем каталоге. Самое замечательное в использовании этих двух DVCS состоит в том, что у них обоих есть только одна папка (.git / .hg) для их конфов, больших двоичных объектов, деревьев и прочего.
Просто вставьте .hg в .gitignore (и .git в .hgignore), и вы более чем хороши.
Вы, конечно, должны удвоить работу при совершении, но я не нашел это трудным для управления.
Эта настройка, на мой взгляд, гораздо более надежна, чем использование каких-либо мостовых решений (они мне не нравятся, так как ужас, который я испытал с git-svn).
источник