在我的Web项目(Django框架)中,我通常有一些内部开发的javascript文件,它们之间共享。这些Web项目存储在单独的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,将其提交给源代码控制,并将更改反映在其他Web项目中?
答案 0 :(得分:3)
您可以考虑将共享库存储在中央存储库和中央Web服务器(例如http://domain.com/shared_libs/
)上,为每个修订版本(或标记或修订版本)提供目录,并嵌入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一样处理修订号,在每次提交时创建一个新的 - 我希望这是正确的。)