Блог

так что да, просто интересно, есть ли в darcs что-нибудь эквивалентное подмодулям git.

то есть, допустим, у меня есть репозиторий (myapp), и в нем есть папка под названием mylibrary. mylibrary на самом деле не имеет никакого отношения к разработке myapp, его просто нужно включить. разработка mylibrary происходит в ее собственном репозитории, но когда кто-то запускает myapp, он также запускает обновленную версию mylibrary. есть идеи?

Моя первая мысль: поскольку darcs проще, чем git (т. Е. Нет ветвей и удаленных устройств — вместо этого вы просто используете каталоги и URL-адреса, и ваша задача — управлять ими), подмодуль darcs не даст намного больше того, чего вы можете достичь со стандартными вещами, такими как подкаталоги или файлы внутри вашего репозитория darcs.

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

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

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

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

Обновление (найдено на сайте darcs):

• http://darcs.net/Ideas/Subrepositories;
• http://darcs.net/Ideas/NestedRepositories.

Итак, darcs заметит другой репозиторий darcs внутри вашей рабочей системы и не коснется его. Итак, первый способ, который я предложил выше, — закрыть (если вы оставите метаданные darcs там).

Второй способ похож на что-то, предложенное в одном из разделов последней ссылки. (Они предлагают скрипт «uglu» для чего-то подобного.)

Еще одна (третья) идея

Импортируйте исправления из репозитория, который вы собираетесь использовать в качестве подмодуля, но сначала переместите все файлы во вложенный каталог. Если бы было возможно просто применить такой движущийся специальный патч один раз, и если бы он был эффективен для всех патчей, которые вы импортируете из репозитория, предназначенного в качестве подмодуля, но не для патчей, которые вы импортируете из «ветки» основного репозитория…

…ну, это мог бы быть специальный вариант pull команды (скажем, import ) и push команды (скажем, export ), которые дополнительно переводили бы пути соответствующим образом.

Я не знаю ни о каком понятии подмодуля для darcs, что означает, что обычным способом ссылки на другой (общий) репозиторий из репозитория darcs были бы символические ссылки.

Поскольку символические ссылки не поддерживаются в darcs, это означает, что вам нужно создать « posthook sh update-symlinks.sh » скрипт подключения для восстановления этих ссылок.

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