Схема размещения ртутного репозитория для нескольких ветвей

У меня есть ряд квази-связанных проектов, которые я хочу контролировать версиями. В SVN я бы установил их как несколько каталогов в рамках одного проекта

/scripts  #updates in sync with project1 & project2
/project1 #requires database
/project2 #requires database
/database

Естественно, что для этого примера игрушек возможны другие варианты SVN, но этот макет имеет преимущества:

  • Я могу копировать файлы между ветвями, сохраняя историю
  • Я могу проверить только подмножество проектов, например svn co repo/project2; svn co repo/database. Это экономит значительное количество памяти и время, если проект1 большой.
  • Простое управление репозиториями, поскольку пользовательский доступ определен один раз для всех проектов.

Эта парадигма не хорошо отображена для mercurial, поскольку вы не можете клонировать один каталог меркуриального репо. Поэтому мой вопрос: какой наиболее распространенный способ хранения больших, тесно связанных проектов в mercurial?

Мои идеи:

  • Несколько репозиториев - теряет историю файлов, которые перемещаются между проектами
  • Леса - кажется, застопорился, и я не уверен, насколько стабильно это расширение
  • Именованные ветки с главным образом несвязанным контентом
  • SubRepos - К сожалению, я запускаю Ubuntu 9.04, который отправляет только hg 1.1.2. В противном случае это будет выглядеть как хороший вариант.

Ответы

Ответ 1

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

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

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

  • Обновите головку ветки, в которую вы хотите скопировать файл: hg update -C project1
  • Слияние в ветке, которую вы хотите скопировать файл: HGMERGE=/bin/false hg merge -r project2
  • Вернитесь к ветке ветки, которую вы хотите скопировать файл: hg revert -a --no-backup -r project1
  • Отмените конкретный файл, который вы хотите скопировать, из главной версии объединенного в ветке: hg revert --no-backup -r project2 path/to/file/in/project2.txt
  • Переместите файл в это место в ветке, которую вы хотите скопировать, чтобы: hg mv path/to/file/in/project2.txt project1/file/path/project2.txt
  • Отметить слияние как разрешенное: hg resolve -am
  • И, наконец, зафиксируйте результат: hg commit -m "A merge to copy project2.txt to project1."

Как я уже сказал, очень уродливо. И это может хорошо работать только в hg 1.3, так как я знаю, что некоторые важные ошибки во взаимодействии revert, merge и resolve были исправлены сравнительно недавно. (IMHO, я подозреваю, Ubuntu намеренно отстает от версий систем управления версиями без bzr.)

Как часто вы действительно хотите копировать файлы между проектами? Почему это произойдет? Вы уверены, что потерять историю будет так плохо?

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