С вашего вопроса не ясно, если вы ищете рабочий процесс (обсуждение monorepo vs multiple repos) или для производительности и масштабирования для огромной базы кода.
Для рабочего процесса я предлагаю поисковый запрос на monorepo. У этого есть свои плюсы и минусы, вам нужно понять вашу ситуацию и текущий рабочий процесс, чтобы решить. Для производительности и масштабирования продолжайте чтение.
Идея remotefilelog заключается не в том, чтобы проверить подкаталог (как вы упомянули), идея состоит в том, чтобы проверить все. Чтобы сделать это эффективным образом, вам нужны два расширения, активно разработанные Facebook:
- remotefilelog. Это дает вам нечто концептуально похожее на мелкий клон. Это уменьшает время
hg clone и hg pull.
- fsmonitor (ранее называемый
hgwatchman, теперь он является частью ртутного ядра). Это значительно сокращает время локальных операций, таких как hg status. Обратите внимание, что fsmonitor не зависит от remotefilelog. Вы можете начать экспериментировать с этим, так как он не требует какой-либо настройки на стороне сервера.
С недавним ртутным (который я настоятельно рекомендую), вы можете сбрить дополнительное время запуска интерпретатора Python с использованием CommandServer + CHg.
Некоторые дополнительные примечания:
- Я оттестирован
fsmonitor. Он работает очень хорошо, при огромных репозициях время hg status уменьшается с 10 секунд до менее 1 секунды (и большая часть этого 1 сек - это время запуска Python, см. Выше для CHg). Если ваш репозиторий действительно огромен, вам может потребоваться тонкая настройка некоторых параметров ядра inotify (или эквивалент на MacOSX). Документация fsmonitor содержит всю необходимую информацию.
- Я не тестировал
remotefilelog, хотя я прочитал все, что нашел, и я уверен, что он работает. В зависимости от того, как осуществляется разработка (у каждого всегда есть подключение к Интернету или нет, у организации есть свое собственное мастер-репо или нет), может быть оговорка: она частично трансформирует децентрализованный hg в централизованный VCS, такой как svn: некоторые операции, которые обычно могут быть (например: hg log и первые hg update в набор изменений в прошлом) теперь потребуют подключения к главному репозиторию.
- Прежде чем рассматривать
remotefilelog, я широко использовал расширение largefiles на огромном репо. Он имеет те же недостатки, что и remotefilelog, и некоторые запутанные угловые случаи для пользователей, которые хотят использовать hg, чтобы сделать все, не потратив время, чтобы понять, как это работает.Если бы мне пришлось управлять другим огромным репо, я бы использовал remotefilelog вместо largefiles, хотя их вариант использования на самом деле не такой.
- Mercurial также имеет
subrepositories (doc1, doc2). Проблема в том, что он изменяет поведение hg в зависимости от того, где вы находитесь в исходном дереве. Опять же, если разработчики не заботятся о том, чтобы понять, как работает hg, это будет просто слишком запутанным.
Дополнительная информация:
Это проливает некоторый свет на как это работает: https://www.mercurial-scm.org/pipermail/mercurial-devel/2014-June/059425.html –