颠覆和依赖
我正在尝试为以下问题找到可行的策略。
我们有几个依赖于我们框架的网络项目。所有内容都存储在我们的 SVN 中，并拥有自己的项目和所有必要的目录结构（主干、标签、分支）。在一个示例中 - 我们有项目 webprj01 和 webprj02，并且我们有一个框架 frm01。所有这些都具有常见的 SVN 项目结构 - 主干、标签、分支。
webprj01 和 webprj01 都依赖于 frm01，并且在现实生活中，frm01 作为 webprj01 和 webprj02 的子目录存在。要在 SVN 中实现此目的，可以设置 svn:external 属性，并且我们可以将 frm01 设置为指向 webprj01 和 webprj02 主干内的 /frm01/trunk 。
为了进行现实生活中的编码，我们必须将所有三个项目作为工作副本签出，并在其自己的工作副本中对特定代码库进行更改。无法将 webprj01/frm01 的更改发布到 SVN。更改需要在frm01工作副本中完成，并通过SVN传输到webprj01/frm01和webprj02/frm01工作副本。
该解决方案在分支时存在依赖关系问题。我创建了一个从 SVN /webprj01/trunk 到 /webprj01/branches/release-1.0.0 的生产分支。在处理第二个项目 webprj02 和 frm01 的两天内，我不再能够通过分支 release-1.0.0 中的 svn:externals 进行稳定的签出。目录frm01已经指向frm01/trunk的新变化。
所描述的只是问题的简化版本。在我们的现实生活中，依赖关系有时会深达五个层次。我希望能够随时从SVN获得稳定的代码。换句话说。当我将 webprj01 分支/标记为 release-1.0.0 时。我希望在创建后一年内获得该特定标签的稳定代码。
很明显，使用 svn:externals 所描述的策略不起作用。遇到这种情况你会有什么体验？没有必要使用一次结帐。即使使用构建脚本或其他解决方案也会有帮助。我正在寻找解决该问题的长期解决方案，该解决方案不会严重依赖人类行为，因为我们很容易犯错误。
I am trying to find a viable strategy to a following problem.
We have several web projects which are dependent on our framework. Everything is stored in our SVN and has its own project with all the necessary directory structure (trunk, tags, branches). In an example - we have projects webprj01 and webprj02 and we have a framework frm01. All of those have usual SVN project structure - trunk, tags, branches.
webprj01 and webprj01 are both dependent on frm01 and in real life frm01 is present as subdirectory of webprj01 and webprj02. To achieve this in SVN it is possible to set svn:external property and we can set frm01 to point to /frm01/trunk inside trunk of webprj01 and webprj02.
To do a real life coding we have to have all three projects checked out as a working copy and do the changes to particular codebase in it's own working copy. There is no way to publish changes from webprj01/frm01 to the SVN. The change needs to be done in frm01 working copy and transfered through SVN to webprj01/frm01 and webprj02/frm01 working copies.
This solution has a problem with dependencies while branching. I make a production branche from SVN /webprj01/trunk to /webprj01/branches/release-1.0.0. In two days while working on second project webprj02 and frm01 I am no longer able to have stable checkout as through svn:externals in branch release-1.0.0. directory frm01 already points to new changes of frm01/trunk.
Described is just a simplified version of the problem. In our real life situations the dependencies go sometimes five levels deep. I'd like to be able to obtain stable code from SVN at any time. In different words. When I branched/tagged webprj01 as release-1.0.0. I want to get stable code for that particular tag in a year from creation.
It is obvious, that described strategy using svn:externals does not do the work. What would be your experience with this situation? It is not necessary to use one checkout. Even using of build scripts or other solution would be of help here. I am looking for a long time solution to the issue which would not depend heavily on human actions as we are prone to mistakes.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在 Java 世界中，我不会尝试仅使用版本控制系统来解决这个问题 - 我会使用像 Maven + 版本控制系统这样的依赖管理工具。
在我工作的地方，我们有一个看起来很常见的设置：
任何“框架”项目都存在于它自己的目录结构（主干、标签、分支）中，就像您已经拥有的那样。这些也使用 Maven 进行管理，每当签入某些内容时，组件的新版本（在大多数情况下是 JAR 文件）就会发布到我们本地的 Maven 存储库（驻留在 Nexus 服务器上）。
任何需要使用“框架”项目的项目都将依赖于框架项目的特定版本 - 每当构建项目时，Maven 就会自动从 Nexus 服务器中提取该版本。
这使我们能够单独发布每个项目和框架组件，但仍然跟踪它们之间的依赖关系。我们甚至可以拥有不同项目使用的多个版本的框架组件，而不会完全失去依赖关系。
到目前为止，这对我们来说效果很好 - 我只能看到两个缺点：
设置需要一段时间，特别是如果您以前没有使用过 Maven。
发布每个项目时会产生一些开销，因为您还想发布每个依赖组件，以避免对其他组件的“trunk”版本（即 Maven 术语中的“SNAPSHOT”版本）产生依赖性。
In the Java world, I would not try to solve this using only a version control system - I would instead use a dependency management tool like Maven + a version control system.
At the place where I work, we have a set-up which seems pretty common:
Any "framework" project lives in it's own directory structure (trunk, tags, branches) like you already seem to have. These are also managed using Maven and whenever something is checked in, a new version of the component (in most cases a JAR-file) is published to our local Maven repositry (which resides on a Nexus server).
Any project which needs to use the "framework" project will have a dependency towards a specific version of the framework project - Maven then automatically pulls this version from the Nexus server whenever the project is being built.
This enables us to release each project and framework component separately, but still keep track of the dependencies between them. We can even have multiple version of the framework components used by different projects without completely losing track of the dependencies.
So far this has worked pretty well for us - I can only see two drawbacks:
It takes a while to set-up, especially if you have not used Maven before.
There is some overhead when releasing each project, since you want to release each dependent component as well, to avoid having dependencies towards the "trunk" version of other components (i.e. the "SNAPSHOT" version in Maven terminology).
Erik 是对的，依赖管理器会帮助你 - 可能想研究一下 Maven 或 ant/ivy。
使用 svn:externals 作为穷人的依赖管理器是一种黑客行为，需要大量的纪律 - 这是一个 PITA 来弄清楚包含哪个版本的框架，然后一些小丑将项目中的外部引用设置为框架的主干，你将很难确定版本之间的增量。
过去我有过 js、css 和xsl 对于许多项目来说很常见，打包为 .tgz 文件并通过简单的 ant 脚本发布到 ivy 存储库，然后项目具有 ant 构建（和 ivy.xml 文件）来解决依赖关系，然后打包整个内容。它有效，但
前端 Web 开发人员在源代码控制方面遇到了困难，更不用说依赖管理了。让他们“了解”足以将对公共模块的更改发布到本地存储库，然后构建一个依赖于它来查看其更改的项目确实很难。
Erik 提到的额外步骤，必须发布多个工件才能为产品做好准备。
粗鲁的遗留设计意味着大多数更改实际上都在公共代码中，可部署的十分之一的版本实际上在其代码中发生了更改......它通常在包含的公共代码中。
严重的是 - svn:externals 作为依赖管理将会变得令人头疼。这是值得投资的。话虽如此，这些人在依赖管理方面遇到了麻烦，但他们不太可能对您现在拥有的许多分支上的 svn:externals 进行排序。
如果我必须重来一次——我会成为专家。
Erik is right, a dependency manager will help you out - may want to look into maven or ant/ivy.
Using svn:externals as a poor person's dependency manager is a hack and requires a lot of discipline - it's a PITA to figure out what version of a framework is included, and then some joker is going to set the external reference in a project to the trunk of the framework and you'll have a really rough time figuring out delta's between releases.
In the past I've had js,css & xsl common to many projects packaged as .tgz files and published to an ivy repo by simple ant scripts, then the projects have ant builds (and ivy.xml files) that resolve the dependencies and then package the whole thing. It worked but
Front end web devs struggled with source control, much less dependency management. It was really hard to get them to 'get it' enough to publish changes to a common module to a local repository and then build a project that depended on it to see their changes.
The extra step Erik mentioned, having to release multiple artifacts to get something ready for prod.
Cruddy legacy design meant most of the changes where actually in the common code, 1 in 10 releases of the deployable actually had changes in it's code... it was usually in the common code included.
seriously - svn:externals as a dependency management is going to get to be a headache. It's worth the investment. Having said that these guys had trouble with dependency management, they'd would be way less likely so sort the svn:externals on many branches you're having now.
If I had to do that stuff over again - I'd go maven.