Вы можете хранить общие библиотеки в центральном репозитории и на центральном веб-сервере (например, http://domain.com/shared_libs/
), иметь каталог для каждой ревизии (или тега, или ревизии, являющейся выпуском), и встраивать библиотеки напрямуюоттуда.
Для 45-й ревизии вам понадобится:
http://domain.com/shared_libs/45/lib1.js
http://domain.com/shared_libs/45/lib2.js
для тега (или любого другого эквивалента Mercurial ...) с именем "0.8-beta3", у вас будет
http://domain.com/shared_libs/0.8-beta3/lib1.js
http://domain.com/shared_libs/0.8-beta3/lib2.js
и т. Д.и т. д.
Процесс создания нового каталога для каждой (значимой) ревизии и экспорта нужных файлов должен быть сравнительно легким в любой операционной системе.
В каждом проекте у вас будут только ссылкик центральному серверу, как это:
<script src="http://domain.com/shared_libs/45/lib1.js">
, таким образом, каждый внутренний проект может выбирать, какую версию общих библиотек использовать - отлично в случае несовместимых изменений или рабочих выпусков, которые необходимо развернутьсразу, и это не может рисковать использованием новой неизвестной версии общих библиотек.
Кроме того, разделяемые библиотеки таким образом полностью отделены от истории изменений проектов.
Если в общей библиотеке происходит важное обновление, вам придется изменить ссылки в каждом проекте (например, с /45/lib1.js
на /52/lib2.js
- но безопасный переход на каждую версию будет более безопасным способом).в любом случае, в конечном счете, в случае, если новый выпуск содержит ошибки, которые нарушают работу других проектов.
Другой вариант - иметь центральное хранилище для общих библиотек и использовать любой эквивалентный для Mercurial внешний вид Subversion для ссылки"библиотекам каждого проекта, чтобы быть в курсе частых обновлений внешних.
(здесь я предполагаю, что Mercurial работает с номерами ревизий так же, как Subversion, создавая новые на каждомсовершить - я надеюсь, что это правильно.)