SVN与外部通用代码
目前，我正在尝试使用相同的代码为多个产品设置存储库。最好的解决方案是创建共享代码的真正库并以这种方式使用它们。然而，目前这需要很长时间。这个想法是拥有一个具有以下树的单个存储库
-trunk-Project1
-Project2
-Shared
项目 1 和 2 都有一个外部来包含共享代码。外部指向特定修订版，以便在处理项目 1 和共享代码时不会破坏项目 2 的构建。由此就产生了一个问题。
当对共享代码进行更改并进行提交（使用 Tortoise SVN）时，项目 1 和共享代码都会拾取更改，并作为单个修订很好地提交到 SVN。但是，当我或同事进行更新时，项目将无法构建，因为 svn external 指向“旧”修订版。
这可以通过更新外部并提交它来解决（让构建在中间中断）。我们可以暂时从外部删除特定的修订版，但是当开发结束时我们必须再次添加它。有没有办法自动执行此操作？
At the moment I'm trying to set up a repository for multiple products using the same code. The best solution would be to make real libs of the shared code and use them that way. However this takes way to much time at the moment. The idea is to have a single repository with the following tree
-trunk-Project1
-Project2
-Shared
Project 1 and 2 both have a external to include the shared code. The external points to a specific revision to not break project2 build while working on project1 and the shared code. From this a problem arises.
When a change is made to the shared code and I do a commit (with tortoise SVN) the changes are picked up for both the project1 and the shared code and are nicely commited to SVN as a single revision. However when I or a colleague does an update the project will not build because the svn external is pointing to the "old" revision.
This can be fixed by updating the external and committing it (leave the build broken in between). We could temporary remove the specific revision from the external, but we have to add it again when development ends. Is there a way to do this automatically?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我认为你有几个选择。首先是按照 Martin 的建议使用带有分支的单个模块。每个活动项目或开发线程都会有一个分支。当您合并回主干时，将拾取对共享代码的更改。
例如
，其次您可以分支共享，这样您就不需要将外部固定到它。这就是您的存储库中的内容
。每个项目都将使用自己的主干视图。这里的危险是分支变得太长 - 您需要遵守合并和删除它们的纪律，也许在每次发布之后。仅当需要对共享进行特定于项目的更改时，才应创建共享的分支。
第三，你继续像现在一样使用外部资源，并承受固定修订的痛苦。如果你这样做的话，我会重新安排你的存储库，就像上面的第二个图一样——项目中的外部内容有点味道。
I think you have a few choices. First is to use a single module with branches as Martin proposes. You would have a branch for each active project, or for a thread of development. Changes to shared code would be picked up when you merge back to trunk.
e.g.
Secondly you could branch Shared so that you do not need to pin an external to it. This is what you'd have in your repository
Each project would use its own view of trunk. The danger here is that the branches get too long - you would need to be disciplined about merging them and deleting them, perhaps after every release. Shared's branches should only be created when project-specific changes to shared are needed.
Thirdly you continue to use externals as you are now and take the pain of pinning revisions. I would rearrange your repo to be like the second figure above if you are doing this - what you have with externals within a project smells a little.
当您有多个存储库并且需要混合所有存储库的源代码来构建项目时，您应该使用 svn:external。根据你的问题，我想说你只有 1 个存储库，因此不需要 svn:external。
你可以使用分支。 Project1 和 Project2 都将更改更改为在自己的分支中共享。您必须制定良好的工作协议，以尽可能频繁地将分支上的更改集成到主干（较小的差异更容易合并），并确保主干上的构建永远不会中断。
我可以推荐 Henrik Kniberg 关于版本控制的论文，它很好地涵盖了这个主题。
You should use svn:external when you have more than one repository and need to mix source from all repositories to build your project. Based on your question I would say you only have 1 repository, hence no need for svn:external.
You could use branches. Project1 and project2 both make changes to shared in their own branch. You would have to make good working agreements to integrate changes on branches as often as possible to the trunk (smaller diff's are easier to merge) and to make sure that the build on trunk never breaks.
I can recommend Henrik Kniberg's paper on Version Control, it covers this subject nicely.
您的问题是 Project1 和 Project 2 需要特定版本的 Shared。所以你需要在布局中明确这一点。
例如，您可以这样做：
-trunk
- 项目1
- 项目1分享
- 项目2
- 项目2分享
- Shared
并且将 Project1Share 和 Project2Share 作为版本化外部，指向 Shared 的特定修订版，并且“Shared”是该共享库代码的最新修订版。
当然，共享模块可以完全位于不同的存储库中。
由于您的子项目依赖于共享代码的特定修订，因此您无法避免管理特定版本以针对您的子项目进行构建：因此您需要将其明确化。
如果规则是 Project1 始终针对最新版本的共享进行构建，而project2针对特定版本进行构建，则project1shared外部可以是无版本的，而project2可以是版本的。
Your problem is that Project1 and Project 2 require specific versions of Shared. So you need to make that explicit in your layout.
For example, you could do this:
-trunk
- Project 1
- Project1Share
- Project 2
- Project2Share
- Shared
And have Project1Share and Project2Share as versioned externals pointing to specific revisions of Shared, and "Shared" being the latest revision of that shared library code.
The shared module can be in a different repos altogether of course.
Since your subprojects depend on specific revisions of the shared code, you cannot avoid managing the specific version to build against your sub-projects: so you need to make it explicit.
If the rule is that Project1 always builds against the latest version of shared, and project2 against specific versions, then the project1shared external can be unversioned and the project2 one versioned.
到目前为止所有好的答案 - 但还有另一种选择：使用标签。
开发完成后，您希望将外部重新链接到 P1 和 P2，两者都指向新的共享项目。在此之前，您希望 P1 和 P2 指向旧的、已知工作的 Shared 版本。
因此，继续在主干上工作，外部指向 HEAD 共享修订版。完成后，将整个批次分支到标签目录（例如，称为 ReleaseX），其中将包含所有这些版本的工作代码。然后你可以继续在主干上工作，而不必担心你会破坏你已经发布的“完成”版本。
如果您在不同时间发布 P1 和 P2，您仍然可以使用这种方法 - 当您将项目放入标签分支时，您将其外部设置为共享项目的当前版本。当下一个项目被标记（并且 Shared 项目被更新）时，旧项目仍将指向 Shared 的正确版本，直到其下一个版本被标记，依此类推。
All good answers so far - but there's another option: use tags.
When development is finished, you want to re-link the externals to P1 and P2 both point to the new Shared project. Until then, you want P1 and P2 to point to the old, known-working version of Shared.
So, continue to work on trunk with externals pointing to the HEAD Shared revision. when you're done, branch the entire lot to a tags directory (call it ReleaseX for example), which will contain working code for all those versions. then you can continue to work on trunk without worrying that you're breaking the 'finished' version you've released.
If you release P1 and P2 at different times, you can still use this approach - when you put the project into the tags branch, you set its externals to the current version of the Shared project. When the next project gets tagged (and the Shared project gets updated), the old project will still point to the correct version of Shared, until its next release is tagged and so on.