Подтвердить что ты не робот

Разделить большое репо на несколько субпопостов и сохранить историю (Mercurial)

У нас есть большая база кода, которая содержит несколько общих проектов, файлы решений и т.д. в одном каталоге SVN. Мы мигрируем в Mercurial. Я хотел бы воспользоваться этой возможностью, чтобы реорганизовать наш код в несколько репозиториев, чтобы клонирование для ветвления имело меньше накладных расходов. Я уже успешно конвертировал наше репо из SVN в Mercurial, сохраняя историю. Мой вопрос: как я разбиваю все разные проекты на отдельные хранилища, сохраняя их историю?

Вот пример того, как выглядит наш единственный репозиторий (OurPlatform):

/OurPlatform
---- Core
---- Core.Tests
---- Database
---- Database.Tests
---- CMS
---- CMS.Tests
---- Product1.Domain
---- Product1.Stresstester
---- Product1.Web
---- Product1.Web.Tests
---- Product2.Domain
---- Product2.Stresstester
---- Product2.Web
---- Product2.Web.Tests
==== Product1.sln
==== Product2.sln

Все это папки, содержащие VS Projects, за исключением файлов решений. Product1.sln и Product2.sln ссылаются на все другие проекты. В идеале я хотел бы взять каждую из этих папок и превратить их в отдельные HG-репозитории, а также добавить новые репозитории для каждого проекта (они будут выступать в роли родительских репозиториев). Затем, если кто-то будет работать над Product1, они будут клонировать репозиторий Product1, в котором содержатся ссылки Product1.sln и subrepo на ReferenceAssemblies, Core, Core.Tests, Database, Database.Tests, CMS и CMS.Tests.

Итак, это легко сделать, просто в hg init'ing в каталогах проектов. Но можно ли это сделать, сохранив историю? Или есть лучший способ устроить это?

ИЗМЕНИТЬ::

Благодаря ответу Ry4an, я смог выполнить свою задачу. Я хотел поделиться тем, как я сделал это здесь для других.

Поскольку у нас было много отдельных проектов, я написал небольшой bash script для автоматизации создания файлов и создания окончательной bat script для фактического преобразования. То, что не было полностью очевидно из ответа, заключается в том, что команда convert нужно запускать один раз для каждой файловой карты, чтобы создать отдельный репозиторий для каждого проекта. Этот script будет помещен в каталог выше рабочей копии svn, которую вы предварительно конвертировали. Я использовал рабочую копию, так как структура файла наилучшим образом соответствовала тому, что я хотел бы получить окончательные новые hg-репозиции.

#!/bin/bash

# this requires you to be in: /path/to/svn/working/copy/, and issue: ../filemaplister.sh ./

for filename in *
do
  extension=${filename##*.} #$filename|awk -F . '{print $NF}'
  if [ "$extension" == "sln" -o "$extension" == "suo" -o "$extension" == "vsmdi" ]; then
    base=${filename%.*}
    echo "#$base.filemap" >> "$base.filemap"
    echo "include $filename" >> "$base.filemap"
    echo "C:\Applications\TortoiseHgPortable\hg.exe convert --filemap $base.filemap ../hg-datesort-converted ../hg-separated/$base > $base.convert.output.txt" >> "MASTERGO.convert.bat"
  else
    echo "#$filename.filemap" >> "$filename.filemap"
    echo "include $filename" >> "$filename.filemap"
    echo "rename $filename ." >> "$filename.filemap"
    echo "C:\Applications\TortoiseHgPortable\hg.exe convert --filemap $filename.filemap ../hg-datesort-converted ../hg-separated/$filename > $filename.convert.output.txt" >> "MASTERGO.convert.bat"  
  fi  
done;

mv *.filemap ../hg-conversion-filemaps/
mv *.convert.bat ../hg-conversion-filemaps/

Этот script рассматривает каждый файл в рабочей копии svn и в зависимости от типа создает новый файл filemap или добавляет его к существующему. Если это действительно просто для того, чтобы поймать разные визуальные файлы студии и поместить их в отдельное репо. Это предназначено для запуска в bash (cygwin в моем случае), но выполнение фактической команды преобразования выполняется с помощью версии hg, поставляемой с TortoiseHg из-за проблем с форкированием/обработкой в ​​Windows (gah, я знаю...),

Итак, вы запускаете файл MASTERGO.convert.bat, который просматривает ваше преобразованное hg-репо, и создает отдельные репозитории с помощью поставляемой файловой карты. После его завершения имеется папка с названием hg-разделенная, которая содержит папку/репо для каждого проекта, а также папку/репо для каждого решения. Затем вам нужно вручную клонировать все проекты в репозиторий решений и добавлять клоны в файл .hgsub. После фиксации создается файл .hgsubstate, и вы готовы к работе!

В приведенном выше примере мой .hgsub файл выглядит так: "Product1":

Product1.Domain = /absolute/path/to/Product1.Domain
Product1.Stresstester = /absolute/path/to/Product1.Stresstester
Product1.Web = /absolute/path/to/Product1.Web
Product1.Web.Tests = /absolute/path/to/Product1.Web.Tests

Как только я переношу эти репозиции на центральный сервер, я буду вручную изменять пути для URL-адресов.

Кроме того, нет аналога с первоначальным репозиторией svn OurPlatform, поскольку теперь все разделено.

Еще раз спасибо!

4b9b3361

Ответ 1

Это абсолютно можно сделать. Вы хотите использовать команду hg convert. Здесь процесс, который я использовал бы:

  • конвертировать все в один репозиторий hg с помощью hg convert с типом источника svn и типом dest hg (похоже, что вы уже сделали этот шаг)
  • создать коллекцию файлов filemap для использования с опцией hg convert --filemap
  • запустите hg convert с типом источника hg и dest type hg, а источник - это меркурийное репо, созданное на первом шаге, и сделайте это для каждой из файлов, созданных вами на шаге 2.

Синтаксис filemap показан в выводе hg help convert, но здесь: gist:

The filemap is a file that allows filtering and remapping of files and
directories. Comment lines start with '#'. Each line can contain one of
the following directives:

  include path/to/file

  exclude path/to/file

  rename from/file to/file

Итак, в вашем примере ваши файлы будут выглядеть так:

# this is Core.filemap
include Core
rename Core .

Обратите внимание, что если у вас есть include, подразумевается исключение всего остального. Кроме того, эта строка переименования заканчивается точкой и перемещает все на один уровень.

# this is Core.Tests
include Core.Tests
rename Core.Tests .

и т.д.

Как только вы создали разбитые репозитории для каждого из новых репозиториев, вы можете удалить все начальное репо, созданное на первом шаге, и начать настройку конфигурации вашего подподразделения в файлах .hgsub.