Там кто-либо - распределенная система управления версиями, которая поддерживает частичный контроль/клон?

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

В распределенном rcs история файла (или блок содержания) является направленным графом без петель, итак, почему Вы не можете только клонировать этот единственный DAG вместо набора всех графиков в репозитории? Возможно, я отсутствую, что-то кроме следующих примеров использования трудно сделать:

  • клонируйте только часть репозитория
  • объедините два репозитория (сохраняющий их истории!)
  • скопируйте некоторые файлы с их историей от одного репозитория до другого

Если я снова использую части чужого кода из нескольких проектов, я не могу сохранить их полную историю. По крайней мере, в мерзавце я могу думать о (довольно сложном) обходном решении:

  1. клонируйте весь репозиторий
  2. удалите все содержание, которым я не интересуюсь
  3. перепишите историю для удаления всего, что не находится в ведущем устройстве
  4. объедините остающийся репозиторий в существующий репозиторий

Я не знаю, возможно ли это также с Подвижным или Базаром, но по крайней мере это не легко вообще. Так есть ли, кто-либо распределил rcs, который поддерживает частичный контроль/клон дизайном? Это должно поддерживать одну простую команду, чтобы получить единственный файл с его историей из одного репозитория и объединить его в другого. Таким образом, Вы не должны были бы думать о том, как структурировать Ваше содержание в репозитории и подмодули, но Вы могли счастливо разделить и объединить репозитории по мере необходимости (экстремальное значение будет одним репозиторием для каждого единственного файла).

15
задан Community 23 May 2017 в 12:09
поделиться

5 ответов

Начиная с версии 2.0, с помощью Mercurial невозможно сделать так называемый "узкий клон", то есть клон, в котором вы получаете данные только для определенного подкаталога. Мы называем это "неглубоким клоном", когда вы получаете только часть истории, скажем, последние 100 ревизий.

Как вы говорите, в общей модели истории на основе DAG нет ничего, что исключало бы эту возможность, и мы работаем над этим. Питер Арренбрехт, автор Mercurial, реализовал два разных подхода для узких клонов, но ни один из них пока не был объединен.

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

7
ответ дан 1 December 2019 в 02:28
поделиться

Для git есть модуль поддерева, позволяющий выделить часть репозитория в новое репо, а затем объединить изменения в / из оригинала и поддерева. Вот его readme на github: http://github.com/apenwarr/git-subtree/blob/master/git-subtree.txt

5
ответ дан 1 December 2019 в 02:28
поделиться

В распределенных rcs история файла (или фрагмента содержимого) является направленным ациклическим графом, так почему бы вам просто не клонировать этот единственный DAG вместо набора всех графов в репозитории?

По крайней мере, в Git, DAG, представляющий история репозитория относится ко всему репозиторию целиком, а не только к отдельному файлу. Каждый объект фиксации указывает на объект «дерево», который представляет все состояние репозитория на тот момент.

Git 1.7 поддерживает «разреженные проверки» , которые позволяют ограничивать размер вашей рабочей копии. Однако все данные репозитория по-прежнему клонируются.

5
ответ дан 1 December 2019 в 02:28
поделиться

В bazaar вы можете разделять и объединять части репозитория.

Команда split позволяет разделить хранилище на несколько хранилищ. Команда join позволяет объединить репозитории. Обе команды сохраняют историю.

Однако это не так удобно, как в SVN-модели, где вы можете проверять/фиксировать для поддерева.

Для bazaar планируется функция под названием Nested-Trees, которая, возможно, позволит делать частичные выгрузки.

3
ответ дан 1 December 2019 в 02:28
поделиться

Я надеюсь, что в одном из этих RCS будет добавлена ​​возможность узкого клонирования. Насколько я понимаю, архитектура GIT (изменения / перемещения отслеживаются по всему репо) очень затрудняет это.

Bazaar гордится тем, что поддерживает множество различных типов рабочих процессов. Отсутствие возможности узкого клонирования запрещает SVN / CVS-подобный рабочий процесс в bzr / hg / git, поэтому я надеюсь, что у них будет мотивация найти способ сделать это.

Новые функции не должны происходить за счет базовой функциональности, такой как возможность получить один файл / каталог из репозитория. «Распределенная» функция современных rcs - это «круто», но, на мой взгляд, препятствует хорошей практике разработки (частые слияния / непрерывная интеграция). Кажется, что всем этим новым RCS не хватает самой базовой функциональности. Даже SVN без реальной поддержки ветвления / тегирования казался шагом назад по сравнению с CVS imo.

3
ответ дан 1 December 2019 в 02:28
поделиться
Другие вопросы по тегам:

Похожие вопросы: