具有Mercurial和Eclipse的项目功能子模块的最佳实践？ [英] Best Practices for Project Feature Sub-Modules with Mercurial and Eclipse?

问题描述

我有几个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库/模块
 | L___java 
 | | L___jar 
 | L___src 
 | | L___css 
 | | L___js 
 | L ___ src-test 
 | L___js 
 L ___ z_business_logic-sub-proj<  -  JS库/模块
 | L___java 
 | | L___jar 
 | L___src 
 | L___css 
 | L___js 
 L ____ master-proj<  - 编译js库的主Web部署模块。 
 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 ___花式型
 | | | | 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

...所有这些都被组合和细化（类似于编译）到 _master-proj / js 目录;在最后一步中， _master-proj 被编译为部署到服务器。

现在关于我想用hg来设置它的方式，我想要做的是将主项目及其子项目从自己的基线存储库复制到客户端的工作副本中，以便模块可以添加（使用hg）到特定客户的工作副本。

此外，当我对一个客户的工作副本进行修改/修复错误时，我会希望能够将更改/错误修复推送回主项目/子项目的基线存储库，目的是最终将更改/修补程序拉入其他客户的工作副本，其中可能包含与需要相同的错误

这样我就可以在不同客户端使用相同的错误修复。

...我不确定使用hg和Eclipse做最好的方法。

我在这里阅读您可以使用hg的转换扩展名将子目录拆分为单独的项目，使用 - filemap 选项。

但是，如果最好使用转换扩展，或者最好将每个模块放在自己的存储库中，并将它们检出到每个客户端的单个工作区中。

解决方案

是的，它看起来像 subrepos 是你正在寻找的，但我认为也许这是错误的问题的正确答案，我强烈怀疑你会遇到类似的使用svn：externals时发生的内容

相反，我建议您将您的组合和最小化的JS文件发布到 artefact库，并使用依赖关系管理器，例如 Ivy 来拉取特定版本的你的文物进入你的主项目。这种方法可以更好地控制您的主项目使用的子项目版本。

如果您需要为特定客户端的子项目修复错误，您可以在该子项目的主干线上进行修复，发布新版本（最好通过自动化构建管道）并更新其主项目以使用新版本。哦，你想在发布之前用他们的主项目测试新版本？在这种情况下，在您推出修复程序之前，请将本地项目组合在一起，并将其发布到本地存储库，并让客户端的主项目选择该版本进行测试。

I have a couple of ANT projects for several different clients; the directory structure I have for my projects looks like this:

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

Within the working copy the modules compile the sub-project into a single Javascript file that is placed in the Javascript directory of the master project.

For example, the directories:

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

...all are combined and minified (sort of like compiled) into a different Javascript filename in the _master-proj/js directory; and in the final step the _master-proj is compiled to be deployed to the server.

Now in regards to the way I'd like to set this up with hg, what I'd like to be able to do is clone the master project and its sub-projects from their own base-line repositories into a client's working-copy, so that modules can be added (using hg) to a particular customer's working copy.

Additionally however, when I do make some changes to/fix bugs in one customer's working copy, I would like to be able to optionally push the changes/bug fixes back to the master project/sub-project's base-line repository, for purposes of eventually pulling the changes/fixes into other customer's working copies that might contain the same bugs that need to be fixed.

In this way I will be able to utilize the same bug fixes across different clients.

However...I am uncertain of the best way to do this using hg and Eclipse.

I read here that you can use hg's Convert Extension to split a sub-directory into a separate project using the --filemap option.

However, I'm still a little bit confused as to if it would be better to use the Convert Extension or if it would be better to just house each of the modules in their own repository and check them out into a single workspace for each client.

解决方案

Yep, it looks like subrepos are what you are looking for, but I think maybe that is the right answer for the wrong question and I strongly suspect that you'll run into similar issues that occur when using svn:externals

Instead I would recommend that you "publish" your combined and minified JS files to an artefact repository and use a dependency manager such as Ivy to pull specific versions of your artefacts into your master project. This approach give you far greater control over the sub-project versions your master project uses.

If you need to make bug fixes to a sub-project for a particular client, you can just make the fixes on the mainline for that sub-project, publish a new version (ideally via an automated build pipeline) and update their master project to use the new version. Oh, you wanted to test the new version with the their master project before publishing? In that case, before you push your fix, combine and minify your sub-project locally, publish it to a local repository and have the client's master project pick up that version for your testing.

这篇关于具有Mercurial和Eclipse的项目功能子模块的最佳实践？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！