Лучшие практики для субмодулей с особенностями проекта с Mercurial и Eclipse

Question

У меня есть пара проектов ANT для нескольких разных клиентов; структура каталогов для моих проектов выглядит следующим образом:

L___standard_workspace
    L___.hg
    L___validation_commons-sub-proj  <- JS Library/Module
    |   L___java
    |   |   L___jar
    |   L___old_stuff
    |   L___src
    |   |   L___css
    |   |   L___js
    |   |       L___validation_commons
    |   L___src-test
    |       L___js
    L___v_file_attachment-sub-proj  <- JS Library/Module
    |   L___java
    |   |   L___jar
    |   L___src
    |   |   L___css
    |   |   L___js
    |   L___src-test
    |       L___js
    L___z_business_logic-sub-proj  <- JS Library/Module
    |   L___java
    |   |   L___jar
    |   L___src
    |       L___css
    |       L___js
    L____master-proj               <- Master web-deployment module where js libraries are compiled to.
        L___docs
        L___java
        |   L___jar
        |   L___src
        |       L___AntTasks
        |           L___build
        |           |   L___classes
        |           |       L___com
        |           |           L___company
        |           L___dist
        |           L___nbproject
        |           |   L___private
        |           L___src
        |               L___com
        |                   L___company
        L___remoteConfig
        L___src
        |   L___css
        |   |   L___blueprint
        |   |   |   L___plugins
        |   |   |   |   L___buttons
        |   |   |   |   |   L___icons
        |   |   |   |   L___fancy-type
        |   |   |   |   L___link-icons
        |   |   |   |   |   L___icons
        |   |   |   |   L___rtl
        |   |   |   L___src
        |   |   L___jsmvc
        |   L___img
        |   |   L___background-shadows
        |   |   L___banners
        |   |   L___menu
        |   L___js
        |   |   L___approve
        |   |   L___cart
        |   |   L___confirm
        |   |   L___history
        |   |   L___jsmvc
        |   |   L___mixed
        |   |   L___office
        |   L___stylesheets
        |   L___swf
        L___src-standard

Внутри рабочей копии модули компилируют подпроект в единый файл Javascript, который помещается в каталог Javascript главного проекта.

Например , каталоги:

• validation_commons-sub-proj
• v_file_attachment-sub-proj
• z_business_logic-sub-proj

... все объединяются и минимизируются (вроде как скомпилированные) в другое имя файла Javascript в каталоге _master-proj/js; и на последнем этапе _master-proj компилируется для развертывания на сервере.

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

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

Таким образом, я смогу использовать одни и те же исправления ошибок для разных клиентов.

Однако ... Я не уверен, как лучше сделать это, используя hg и Eclipse.

I прочитайте здесь , что вы можете использовать hg's Convert Extension , чтобы разделить подкаталог на отдельный проект с помощью опции --filemap.

Однако я все еще немного сбит с толку относительно того, что было бы лучше использовать Convert Extension или было бы лучше просто разместить каждый из модулей в их собственном репозитории и проверить их в единую рабочую область для каждого клиента.

Answer 1

Да, похоже, подпункты - это то, что вы ищете, но я думаю, что, возможно, это правильный ответ на неправильный вопрос, и я сильно подозреваю, что вы столкнетесь с похожими проблемами. что происходит при использовании svn: externals

Вместо этого я бы порекомендовал вам "опубликовать" ваши объединенные и уменьшенные файлы JS в хранилище артефактов и использовать диспетчер зависимостей, такой как Ivy , чтобы перетащить определенные версии ваших артефактов в Ваш главный проект. Этот подход дает вам гораздо больший контроль над версиями подпроекта, которые использует ваш главный проект.

Если вам нужно исправить ошибки в подпроекте для конкретного клиента, вы можете просто внести исправления в основную линию этого подпроекта, опубликовать новую версию (в идеале через конвейер автоматической сборки *) 1014 *) и обновите свой мастер-проект для использования новой версии. О, вы хотели протестировать новую версию с их мастер-проектом перед публикацией? В этом случае, перед тем как отправить исправление, объедините и сверните свой подпроект локально, опубликуйте его в локальном репозитории и попросите главный проект клиента выбрать эту версию для тестирования.