Маючи реппо Git і mercurial в одному каталозі

Я поясню свою проблему,

Зараз я використовую внутрішню установку gitorious за допомогою git. Я хотів би почати тестування FogBugz та Kiln з Fog Creek, який використовує mercurial. Я хотів би хоча б на короткий час продовжити розвиток, використовуючи обидва рішення.

Хтось знає про якісь довгострокові серйозні наслідки наявності кишки та ртутного репо в одному каталозі. Або є кращий спосіб синхронізації сервера git та mercurial.

Я спробував це з тестовим репо, і я не бачив жодних проблем.

Дякуємо за будь-яку допомогу.

Я знайшов міст hg-git досить зручним в іншому напрямку (викриваючи деякі речі на Github, які спочатку були побудовані за допомогою Mercurial для контролю джерел). В основному ви "просто" використовуєте mercurial, створюєте закладку, що посилає "master" на "default", коли ви готові натиснути на git repo і натиснути. Витягнути з git працює аналогічно тому, як це відбувається, коли ви тягнете з віддаленого репо. У цьому сценарії ви не закінчуєте файли .git + .hg, у вас просто є мізерні файли у вашому локальному вікні, якщо ви не переходите на git цілком, і в цьому випадку ви, ймовірно, зробите git clone в новому. каталог.

Існує подібний проект для користувачів git, які хочуть натискати / витягувати з сховищ Mercurial, але я не маю прямого досвіду з цим. Дивіться https://github.com/offbytwo/git-hg

Окрім потенціалу випадкової перевірки у купі прихованих папок із вашої іншої системи управління джерелом, я не бачу жодної реальної проблеми із виконанням hg init в git repo; мені здається менш незграбним використовувати міст, і явно вибирати, коли натиснути на іншу систему dvcs.

Я використовував як mercurial, так і git в одному проекті, в одному робочому каталозі. Чудова річ у використанні цих двох DVCS - це те, що вони обидва мають лише одну папку (.git / .hg) для своїх конфіденцій та крапок, дерев та ін.

Просто вставте .hg в .gitignore (і .git in .hgignore), і вам більше ніж добре.

Ви, звичайно, повинні подвоїти роботу під час вчинення, але мені це не важко було керувати.

Ця настройка, на мою думку, набагато надійніша, ніж використання будь-яких мостових рішень (мені це не подобається з моменту жах, який я мав з git-svn).