Какой хороший способ синхронизации внутреннего кода JavaScript между проектами? - PullRequest
3 голосов
/ 19 июня 2010

В моих веб-проектах (фреймворк Django) у меня обычно есть несколько внутренне разработанных файлов javascript, которыми они делятся.Эти веб-проекты хранятся в отдельных хранилищах исходного кода Mercurial.Вот соответствующая структура каталогов:

+ static
--+ css
--+ images
--+ js
-----+ thirdparty
-----+ mycompany
--------+ shared_lib1.js
--------+ shared_lib2.js
--------+ project_only_lib.js
-----+ tests

Ссылка на скрипты в html выглядит так:

<script src="/static/js/mycompany/shared_lib1.js" type="text/javascript"></script>

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

Это выглядит довольно глупо.

Есть ли что-то еще, что я должен сделать, что позволяет мне изменять javascript, передать его в систему контроля версий и отразить ли изменения в других веб-проектах?

1 Ответ

3 голосов
/ 19 июня 2010

Вы можете хранить общие библиотеки в центральном репозитории и на центральном веб-сервере (например, 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, создавая новые на каждомсовершить - я надеюсь, что это правильно.)

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...