Моя первая мысль: поскольку darcs проще, чем git (т. Е. Нет ответвлений и удаленных - вместо этого вы просто используете каталоги и URL-адреса, и ваша задача - управлять ими) субмодуль darcs не даст намного больше, чем вы можете достичь с помощью стандартных вещей, таких как подкаталоги или файлы внутри репозитория darcs.
Если вам нужен подмодуль для того, чтобы исправить определенное состояние источника используемой библиотеки, вы можете просто поместить копию репозитория библиотеки в качестве подкаталога и добавить ее в darcs вашего проекта. По сравнению с git, у этого недостатка будет раздутая передача данных, когда кто-то получит ваш репозиторий.
Если вам нужен субмодуль, чтобы сообщить тем, кто получает ваше хранилище, где взять обновленный источник библиотеки (без увеличения размера хранилища), вы можете просто поместить URL-адрес и инструкцию в файл README. или сценарий, или что угодно. По сравнению с git, недостатком является то, что состояние исходного кода библиотеки в том виде, в каком оно было при использовании, не будет записано в вашем коммите, поэтому люди могут получить другую версию библиотеки, и компиляция не удастся, и это непонятно почему.
Итак, действительно интересной целью подмодуля может быть не просто сообщить людям, откуда взять библиотечный источник (как вы пишете в вопросе), но записать состояние подпроекта, который вы фактически использовали для компиляции ваш проект, а не раздувать репо тем, кто не хочет получать источник подпроекта.
Вероятно, эта цель также может быть достигнута путем хранения более сложных метаданных о состоянии подпроекта и более сложной перехвата для получения именно этого состояния (или - по выбору - другого состояния) подпроекта. AFAIK из документации, для таких подмодулей нет встроенного механизма.
Обновление (найдено на сайте darcs):
Итак, дарки заметят еще одно репо в вашей работе, и они не коснутся его. Итак, первый способ, который я предложил выше, - это закрытие (если вы оставите там метаданные darcs).
Второй способ похож на то, что предлагается в одном из разделов последней ссылки. (Они предлагают сценарий "uglu" для чего-то вроде этого.)
Другая (3-я) идея
Импортируйте патчи из репозитория, который вы хотите иметь в качестве подмодуля, но сначала переместите все файлы в поддиректорий. Если бы можно было просто применить такой движущийся специальный патч один раз, и если он действовал для всех патчей, вы импортируете из репозитория, предназначенного для использования в качестве подмодуля, но не для патчей, которые вы импортировали из «ветви» основной репо ...
... ну, это может быть специальный вариант команды pull (скажем, import) и команды push (скажем, export), который дополнительно переводит пути соответственно.