Ртутный репозиторий узкий клон?

Question

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

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

Репозиторий Framework:

• документы /
• deploy /
• lib /
• тесты /

Репозиторий приложений:

• application /
• config /
• lib /
• tests /
• www /

Мне бы хотелось, чтобы каталог lib приложения содержал копию lib / фреймворков.каталог.Я делал это, используя svn: externals.Теперь я знаю, что Mercurial поддерживает концепцию субпозиториев , но это не похоже на «правильное» решение, поскольку оно фактически не тянет в каталог lib /, как я хотел, как выВсе равно придется тянуть и толкать изменения вручную .Кроме того, после клонирования репозитория фреймворка вы получите всех , а не только каталог lib /.Мне нужен только каталог lib /, а не тесты или документы.

Теперь я придумал два разных решения этой проблемы, но мне интересно, какое из них лучше.Первым решением было бы клонировать фреймворк в другом каталоге и создать символическую ссылку в каталоге lib / приложения, которая указывает на каталог lib / фреймворка.Помещение символической ссылки в .hgignore должно убедиться, что все в порядке, я думаю?Это означает, что вы можете редактировать код фреймворка и фиксировать его, а также редактировать код приложения и фиксировать его.

Другой вариант - иметь несколько репозиториев.Фреймворк полностью вытащен, что означает, что вы получите каталоги docs /, deploy /, test / etc., которые не нужны для использования фреймворка.Я подумал, что, может быть, создание репозитория исключительно для библиотеки может быть решением, хотя я искренне сомневаюсь в этом, поскольку модульные тесты очень зависят от самой библиотеки.

Кто-нибудь знает достойное решение этой проблемы?

Answer 1

Вы должны поместить отдельные компоненты в свои репозитории.Затем, когда вы создаете приложение, вы можете использовать расширение convert для создания репозитория фреймворка pullabale из обычного:

$ hg convert --filemap map.txt framework new-framework

с map.txt, содержащим переименования / include/ исключает (следующий должен включать только каталог lib и перемещать все в него в корень хранилища):

include lib
rename lib .

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

$ cd project
$ hg pull -f ../new-framwork
$ hg merge

Теперь, когда разработка продолжается, вам просто нужно каждый раз заново создавать конвертированный репо, прежде чем вытащитьи ты в порядке.На самом деле у нас есть hook в нашем репозитории фреймворка, который воссоздает конвертированное репо в каждой группе изменений (= каждый толчок).

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

Answer 2

Вы должны разделить библиотеки в отдельный репозиторий, если вам нужно сослаться только на это.

При условии, что вы на самом деле do должны ссылаться только на это.В чем проблема со ссылкой на репозиторий, содержащий каталог lib + другие вещи, кроме «он не чувствует себя правильно»?

Что касается «все еще тянуть и толкать вручную», когда вы тянетеосновной клон, он также вытянет вложенные элементы, но не обновит их до более новой ревизии, и это хорошо, вам нужно сделать это вручную, как и в Subversion.