Как разбить большой ртутный репозиторий на более мелкие - PullRequest
Новая
       24

Как разбить большой ртутный репозиторий на более мелкие

2 голосов
/ 13 сентября 2011

Это дубликат этого вопроса, , но особенно в отношении Mercurial.

У меня есть массивный репозиторий Subversion, который я преобразовал в Mercurial.Теперь это выглядит так: 

MassiveFolder/
   .hg/
   bin/
   common/
   projA/
   projB/
   ...
   projX/
   makefile
   README

Я бы хотел, чтобы каждый подпроект отслеживался в своем собственном репозитории для повышения производительности.Обратите внимание, что все они встроены в одну папку bin.Я не думаю, что это будет проблемой, но я не уверен, что мне нужно будет что-то сделать, чтобы скорректировать пути.Можно с уверенностью предположить, что каждый разработчик будет клонировать репозитории в одной и той же структуре, но если бы был какой-то способ создать мета-репозиторий, который бы это гарантировал, было бы еще лучше.

Есть ли стандартный способделать это?Что мне делать с такими файлами, как make-файл и readme, которые находятся в корневой папке?

Если мне придется начать с импорта в hg через какой-то другой процесс, это тоже не должно быть проблемой.Просто требуется слишком много времени, чтобы выполнить стандартные операции с монолитным хранилищем, даже если он уже выдувает svn из воды.

Ответы [ 2 ]

4 голосов
/ 13 сентября 2011

Вы можете использовать расширение Преобразования Mercurial (которое вы, вероятно, уже знаете, поскольку вы преобразовали хранилище из SVN в HG) с опцией -filemap длясоздайте отдельные репозитории HG для подпапок SVN.
Вам нужна, в частности, директива include:

Директива include вызывает включение файла или всех файлов в каталоге.в целевом хранилище и исключении любого другого элемента, который не входит в правило включения.

Затем вы можете использовать Mercurial Subrepositories , чтобы настроить хранилища в нужной папке.структура:

Подпозитории - это функция, позволяющая рассматривать коллекцию репозиториев как группу.Это позволит вам клонировать, фиксировать, отправлять и извлекать проекты и связанные с ними библиотеки как группу.

2 голосов
/ 13 сентября 2011

Мой подход, который я успешно использовал в небольших репозиториях, следующий:

Определите список меньших репозиториев и их взаимосвязь.

  • клон из исходного хранилища
  • hg rm все файлы, которые вам не нужны

Если подпроекты переплетаются с Make-файлом верхнего уровня, вы можете добавить репозиторий верхнего уровня, который будет подпрепарировать в меньших репозиториях.

Этот подход поддерживает историю и не заставляет людей откидываться. Если вы хорошо разбираетесь в истории, конвертирование в порядке и уменьшит размер хранилища.

Слово (или несколько) предупреждений: у субрепозиторов довольно сложное поведение по сравнению с простотой операций с одним репозиторием. Некоторые операции повторяются, другие нет. Объединять в частности рекурсы, что обычно дает мне припадки. Определить состояние всей системы может быть непросто, особенно с учетом увеличения числа суб-репозиториев (я помогаю управлять проектом с> 100 суб-репозиториями, и да , это был логичный и лучший способ справиться с этим) ,

...