典型的 SVN 存储库结构对于持续集成来说似乎不是最佳选择
我已经像 Subversion 书中建议的那样设置了 SVN 存储库，这也是我以前的公司的做法。它看起来像这样：
/trunk
/branches
/tags
/extlibs
/docs
其中前三个非常明显，extlibs 用于第三方程序集，我们通常不会自己重新编译。
所有这些对于日常开发都非常有用。
现在我已经安装了 TeamCity 并运行了构建、单元测试、代码覆盖率和代码分析。一切都很棒，除了这种代码结构会导致下载太多代码。
因此，在我看来，这是第 22 条陷阱：当我只需要 /trunk 和 /extlibs 时，从 SVN 存储库下载上述所有文件夹是愚蠢的。但我只能在 TeamCity VCS 设置中指定一个要下载的存储库文件夹。因此，另一种可能性是将 /extlibs 文件夹放入 /trunk 中，但为了编译分支， /extlibs 也必须进入所有这些文件夹（因为我通常分支主干，而不是单个子文件夹......这看起来更加邪恶，因为 /extlibs 实际上可能比 /trunk 和 /branches 更大，所有二进制文件都存储在那里......
你们有什么建议吗？谢谢！
I've set up our SVN repository like the Subversion book suggests, and this is also how my previous companies have done it. It looks something like this:
/trunk
/branches
/tags
/extlibs
/docs
where the first three are pretty obvious, and extlibs is for 3rd party assemblies that we wouldn't typically recompile ourselves.
All of this works great for the daily development stuff.
Now I've installed TeamCity and have builds, unit tests, code coverage, and code analysis running. Everything is great, except for the fact that this code structure results in too much code getting downloaded.
So here's the catch 22, in my opinion: it's silly to download all of aforementioned folders from the SVN repo when I only need /trunk and /extlibs. But I can only specify one repo folder to download in the TeamCity VCS settings. So then the other possibility is to put the /extlibs folder into /trunk, but in order to compile branches, /extlibs would have to go into all of those as well (since I usually branch the trunk, and not individual subfolders... and this would seem infinitely more evil since /extlibs could actually be larger than /trunk and /branches, with all of the binaries stored there...
Do you guys have any suggestions for me? Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
将 TeamCity 设置为仅下载
/trunk。将/trunk/extlibs设为指向/extlibs的外部。对所有/branches执行相同的操作。这将允许您在/trunk和所有/branches之间共享/extlibs，同时仍然为它们保留单个根文件夹。更新：当我说将
/extlibs设为/trunk/extlibs中的外部时，我指的是 SVN externals 属性。假设您的 SVN 服务器是 svn://yoursvnserver/svn，您可以使用以下 svn 命令来执行此操作：svn.exe propset svn:externals svn://yoursvnserver/svn/trunk -F externals_defs。您
可以参考 svn.exe help propset 了解有关文件格式的更多详细信息，但在最简单的形式中，它会包含这样一行：
Once you set the SVN externals property on后备箱，你会提交它。从那时起，签出
/trunk（包括 TeamCity）的每个人都将在/trunk/extlibs中获得/extlibs的副本。当然，您必须稍微更改引用，以便它们现在指向/trunk/extlibs，以便您的构建独立于/trunk树中。Set TeamCity to download only
/trunk. Make/trunk/extlibsan external that points to/extlibs. Do the same for all/branches. This would allow you to share/extlibsbetween/trunkand all/branches, while still having single root folder for each of them.Update: When I said to make
/extlibsan external in/trunk/extlibs, I was referring to the SVN externals property. Assuming your SVN server issvn://yoursvnserver/svn, you can do this with the following svn command:svn.exe propset svn:externals svn://yoursvnserver/svn/trunk -F externals_defs.txt
You can refer to
svn.exe help propsetfor more details on the format of the file, but in the simplest form, it'll have one line like this:Once you set the SVN externals property on the trunk, you'll commit it. From there on, everybody that checks out
/trunk(including TeamCity) will get in/trunk/extlibsa copy of/extlibs. Of course, you will have to change your references a bit so that they point to/trunk/extlibsnow, so that your build is self-contained in the/trunktree.我想说，将 extlibs 放入主干实际上是一个好主意，它不仅解决了您的问题，还解决了另一个问题。
当您需要发布以前的标记构建但此后您已经更新了 extlibs 中的一些库时，会发生什么情况？您必须浏览历史记录才能找到标记该构建时当前的 extlib 版本。
I'd say that putting extlibs in the trunk is actually a good idea, that not only solves your problem but another as well.
What happens when you need to release a previous tagged build but you've updated some of the libraries in extlibs since then? You have to fish through the history to find a version of extlibs that was current when that build was tagged.
我也想回答一个小问题。这里关于如何指示 Subversion 将外部库的“当前”副本保留为 trunk 的一部分的所有答案基本上是在这种特殊情况下前进的正确方法。
但是，如果出于某种原因您想要在 TeamCity 中提取部分存储库（正如您所要求的），您也可以这样做。
当您编辑构建配置时，在第二个选项卡（用于版本控制设置的选项卡）上，您可以为每个附加的 VCS 根设置一个用于签出规则的设置。
单击该构建配置的 VCS 根网格右侧的“编辑签出规则”链接，然后输入以下内容（根据您的示例）：
这将首先将所有内容标记为“不下拉”，包括以下文件和子文件夹根目录，然后将 trunk 和 extlibs 标记为“将它们拉下来”。
您可以在此处阅读有关结帐规则的更多信息。
I'd like to chip in a smallish answer as well. All the answers here about how to instruct Subversion to keep a "current" copy of the external libraries as part of trunk is basically the right way to go forward in this particular case.
However, if for some reason you want to pull down parts of a repository in TeamCity, like you asked, you can do that as well.
When you edit the build configuration, on the second tab, the one for version control settings, you have a setting for each attached VCS root, for checkout rules.
Click on the "edit checkout rules" link to the right in the VCS root grid for that build configuration and enter the following (as per your example):
This will first flag everything as "do not pull down", both files and subfolders of the root, and then flag both trunk and extlibs as "do pull these down".
You can read more about the checkout rules here.
看来您有两个不同的问题需要解决：
对于您的 VCS，请保留现有设置 - 在您的存储库的根目录。在每个构建配置中，您可以添加结帐规则来修剪结帐到正确的文件夹。
例如，您可以使用以下命令使 trunk 文件夹成为签出的根文件夹：
或者对于分支，您可以执行以下操作：
如果需要，您可以添加多个签出规则，包括添加 extlib 文件夹中的任何文件/文件夹：
您甚至可以使用签出规则删除文件/文件夹：
对于您的外部库，如其他答案中所述，您可以使用 SVN 包含外部文件夹。但是，我不会对包含整个 extlibs 文件夹采取严厉措施。仅包含构建项目所需的特定库修订。另外，请确保您的 extlibs 文件夹受到良好保护，不会被更改。通过对外部进行细粒度的处理，您可以避免尝试构建旧版本的问题，因为您的项目将链接到正确的版本。如果您启用了触发构建，您还可以避免库更改触发构建。例如，您可以像这样配置 srv:external libs：
It looks like you have two different issues you need to address:
For your VCS, leave your setup as you have it - at the root of your repository. In each build configuration, you can add checkout rules to prune your checkout to the right folders.
For instance, you can use the following to make the trunk folder the root folder of the checkout:
Or for a branch, you can do something like:
You can add multiple checkout rules if desired, including adding any files/folders from your extlib folder:
You can even remove files/folders using checkout rules:
For your external libs, as stated in other answers, you can include external folders using SVN. However, I would not get heavy handed with the inclusion of the entire extlibs folder. Only include the specific library revisions that you need to build the project. Also, make sure your extlibs folders are well-protected from change. By being fine-grained about your externals, you can avoid the issue of trying to build an old version because your project will be linked to the correct version. If you have triggered builds enabled, you will also avoid a library change triggering a build. For example, you could configure your snv:external libs like so:
一种方法是将 extlib 存储在它们自己的“项目”结构中。将它们视为主项目引用的单独项目，而不是主项目的一部分。然后设置 TeamCity 在修改这些二进制文件时“构建”这些二进制文件（这只是将它们拉下来）。由于您的主项目依赖于这些二进制文件，因此当它们“构建”时，它应该触发依赖于它们的项目的构建。这样，您就不必在每次准备构建主项目时都拉取二进制文件，而是仅在它们重新编译并提交到 SVN 时才拉取。
One approach is to store the extlibs in their own "project" structure. Treat them like a seperate project that your main project references instead of a part of the main project. Then set TeamCity to "build" these binaries(which is simply to pull them down) when they are modified. Since your main project is dependent on these binaries, when they are "built" it should trigger a build of the projects that depend on them. That way you aren't pulling down the binaries each time you get ready to build your main project but only as they are recompiled and committed into SVN.