在项目之间同步内部 JavaScript 代码的好方法是什么？
在我的 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 项目中吗？
In my web projects (Django framework) I typically have a few internally developed JavaScript files that are shared among them. These web projects are stored in separate mercurial source code repositories. Here's the relevant directory structure:
+ static
--+ css
--+ images
--+ js
-----+ thirdparty
-----+ mycompany
--------+ shared_lib1.js
--------+ shared_lib2.js
--------+ project_only_lib.js
-----+ tests
Linking to the scripts in HTML looks like so:
<script src="/static/js/mycompany/shared_lib1.js" type="text/javascript"></script>
Currently, when I make a change (say fix a bug) in one of the shared libs and check it in, the updated code only exists in the one repository. So, for now, I manually copy the changes over to the other repositories and check it in.
This seems pretty dumb.
Is there something else I should be doing that allows me to change the JavaScript, commit it to source control, and have the changes reflected in the other web projects?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您可以考虑将共享库存储在中央存储库和中央 Web 服务器上（例如
http://domain.com/shared_libs/），为每个修订版（或标签或修订版）提供一个目录这是一个版本），并直接从那里嵌入库。对于修订版 45，您将拥有：
对于名为“0.8-beta3”的标签（或任何 Mercurial 等效项...），您将拥有
等等。
为每个（有意义的）修订版创建新目录的过程以及在任何操作系统上导出正确的文件都应该相对容易。
在每个项目中，您只会像这样引用中央服务器：
这样，每个内部项目都可以选择要使用的共享库版本 - 非常适合不兼容的更改或需要部署的生产版本立即，并且不能冒险使用新的未知版本的共享库。
此外，通过这种方式，共享库与项目的修订历史记录完全分离。
如果共享库中发生重要更新，您必须更改每个项目中的引用（例如从
/45/lib1.js更改为/52/lib2.js- 但从长远来看，对每个版本的受控切换将是更安全的方式，以防新版本包含破坏其他项目的错误。另一个选择是为共享库建立一个中央存储库，并使用 Mercurial 的任何内容。与 Subversion 的外部版本相同的方法是“链接”到每个项目的库，以保持外部版本的频繁更新
（我在这里假设 Mercurial 与 Subversion 一样处理修订版本号，创建一个新的版本号） 。每次提交 - 我希望这是正确的。）
You could consider storing the shared libraries in a central repository and on a central web server (e.g.
http://domain.com/shared_libs/), having a directory for each revision (or tag, or revision that is a release), and embedding the libs directly from there.For revision 45, you would have:
for the tag (or whatever the Mercurial equivalent is...) named "0.8-beta3", you would have
etc. etc.
The process of creating a new directory for each (meaningful) revision and exporting the right files should be comparably easy on any operating system.
In each project, you would only have references to the central server like this:
that way, every in-house project can choose which version of the shared libraries to use - great in case of incompatible changes, or production releases that needs to be deployed straight away and that can't risk using a new unknown version of the shared libraries.
Also, the shared libraries are completely separated from the projects' revision history this way.
If an important update occurs in the shared library, you would have to change the references in each project (e.g. from
/45/lib1.jsto/52/lib2.js- but a controlled switch to the each version will be the safer way anyway in the long run, in case a new release contains bugs that break the other projects.Another option would be having a central repo for the shared libraries, and using whatever Mercurial's equivalent of Subversion's externals are to "link" to the libraries from each project, keeping up to date with frequent updates of the external.
(I'm making the assumption here that Mercurial deals with revision numbers just as Subversion does, creating a new one on each commit - I hope that is correct.)