Nant：如何构造 svn:externals 以构建引用第 3 方 dll 的类库
我正在使用 subversion 和 nant （以及 Visual Studio IDE），
我一直在遵循 http 上建议的项目结构://blog.jpboodhoo.com/NAntStarterSeries.aspx 提倡自包含的颠覆目录，开发人员可以在其中进行签出并立即一步构建项目。
我的存储库结构如下：
/Repo
/MainProject
/trunk
/doc <-- documentation
/lib <-- binary-only DLLs
/src <-- source code for MainProject
/tools <-- holds tools like nant, nunit, etc
...
/ClassLibrary1
/trunk
/doc
/lib
/src
/tools
...
/ClassLibrary2
/trunk
/doc
/lib
/src
/tools
不清楚的是如何构建一个具有类库的项目，而类库又引用第三方库 dll 本身。
目前，我有一个带有工作目录的主项目，例如
示例：
/MainProject
/build
/lib
/src
/MainProject
/ClassLibrary1 <-- svn external to svn://server/repo/ClassLibrary1/trunk/src
/ClassLibrary2 <-- svn external to svn://server/repo/ClassLibrary2/trunk/src
/tools
...
构建 MainProject 时，我编译类库并将 dll 输出到构建文件夹。 但是，类库本身具有它们引用的第 3 方纯二进制 DLL。
我的问题是为了构建 MainProject，我必须以某种方式将 3rd 方 DLL 从类库中获取到构建输出中。 我怎么做？
想法： 1. 我应该将这些第 3 方 dll 的副本存储在 MainProject 的 lib 文件夹中吗？ 2. 或者我的 svn:external 引用应该指向类库项目的主干而不是 src，以便我可以访问类库的 lib 文件夹？ 3. 我应该对单个文件使用 svn:externals 的 subversion 1.6 功能吗？
I'm using subversion and nant (and visual studio IDE)
I've been following the suggested project structure at http://blog.jpboodhoo.com/NAntStarterSeries.aspx which advocates self contained subversion directories where a developer can do a checkout and immediately build a project in a single step.
My repo structure is like:
/Repo
/MainProject
/trunk
/doc <-- documentation
/lib <-- binary-only DLLs
/src <-- source code for MainProject
/tools <-- holds tools like nant, nunit, etc
...
/ClassLibrary1
/trunk
/doc
/lib
/src
/tools
...
/ClassLibrary2
/trunk
/doc
/lib
/src
/tools
What's not clear is how to structure a project that has class libraries which in turn reference third party library dll's themselves.
Currently, I have a main project with a working directory like
Example:
/MainProject
/build
/lib
/src
/MainProject
/ClassLibrary1 <-- svn external to svn://server/repo/ClassLibrary1/trunk/src
/ClassLibrary2 <-- svn external to svn://server/repo/ClassLibrary2/trunk/src
/tools
...
When building MainProject, I compile the class libraries and output the dll's to the build folder. However, the class libraries themselves have 3rd party binary-only DLL's that they reference.
My questions is in order to build the MainProject I have to somehow get the 3rd party DLL's from the class libraries into the build output. How do I do that?
Thoughts:
1. Should I store copies of these 3rd party dlls in the MainProject's lib folder?
2. Or should my svn:external reference be to the trunk of the class library project rather than the src so that I can access the class library's lib folder?
3. Should I use the subversion 1.6 feature of svn:externals to individual files?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
就我个人而言，我引入了引用的库的主干。
（实际上，我引入了标签的根，但这不是重点）。
如果您保留所需 dll 的单独副本，那么您实际上并不允许引用的库确定其自身所需的内容，因为所有逻辑都在项目中重复。 如果您使用多个外部引用或文件外部来引入代码和 dll，也会发生同样的情况。
我的原则是 - 库知道它需要什么，对库的单个外部引用可以获取该库及其所需的一切。
这样，如果您更改库的引用，您可以确信任何和所有项目都会选择它。 （如果 IDE 不支持此功能，那是 IDE 的问题，而不是 subverion 的问题）。 作为一个项目，您还可以确信，如果您更改所指向的库的版本，您也会自动获得正确的引用，并且不需要调试构建失败来找出问题所在。
Personally I bring in the trunk of the referenced libraries.
(Actually, I bring in the root of a tag, but that's beside the point).
If you keep a separate copy of the required dll's, then you're not really allowing the referenced library to determine what it needs for itself because all that logic is duplicated in the project. The same thing happens if you use multiple externals references or file externals to bring in the code and the dll's.
My principle here is that - the library knows what it needs, a single external reference to the library can get that library and everything it needs.
That way if you change the library's references, you can be confident that any and all projects will just pick that up. (if the IDE doesn't support this, that's the IDE's problem, not subverion's). You can also be confident as a project that if you change the version of the library you're pointing to, you'll automatically get the right references as well, and don't need to go debugging build failures to work out what's gone wrong.
我应该将这些第 3 方 dll 的副本存储在 MainProject 的 lib 文件夹中吗？我更喜欢将任何外部库存储在 trunk 下但位于源代码旁边的二进制目录中......或者将其称为引用，这样一来，任何开发人员都可以获取最新版本，并且所需的一切都将下降。 它本身不需要成为项目的一部分。 只需在执行构建时可以访问它即可。
或者我的 svn:external 引用应该是类库项目的主干而不是 src，以便我可以访问类库的 lib 文件夹？ 我不喜欢这种方法，因为它使得新开发人员的启动和运行过程变得更加复杂。 我认为当程序集对其自身具有一定的重要性时，它可以进入自己的存储库。 但我永远不会引用它的输出。 它应该有一个构建过程，以促进一种将输出“部署”到上述引用或依赖项目录的机制。 然而，像这样的自动化部署可能会充满问题。 如果装配体有自己的流程，那就更好了。 当程序集的新版本发布时，需要它的项目的开发人员将手动接受它。 然后他们可以测试它，接受它，并将其放入他们的构建过程中。 显然，如果该程序集每天都会更改，则可能需要一些自动化。
我应该对单个文件使用 svn:externals 的 subversion 1.6 功能吗？不。我更喜欢将项目/解决方案保留为独立的实体。 将帐篷分散在各处会让依赖变得更加痛苦。 尽可能保持孤岛...尽可能手动引入新事物...或者在事物变化允许的频率下以手动方式引入。
Should I store copies of these 3rd party dlls in the MainProject's lib folder? I prefer to store any external libraries in a binaries directory under trunk but next to source...or call it references, dependencies, etc. This then allows any developer to get latest and all that is needed will come down. It doesn't need to be part of the project per se. It just needs to be accessible when the build is performed.
Or should my svn:external reference be to the trunk of the class library project rather than the src so that I can access the class library's lib folder? I don't prefer this approach as it makes the process of getting a new developer up and running more convoluted. I think an assembly can go into its own repository when it has a level of importance on to itself. But I would never reference its output. It should have a build process wrapped around it that promotes a mechanism to "deploy" the output to the above references or dependencies directory. However automating the deployment like that might be fraught with issues. It would be better if the assembly had its own process around it. And when a new version of the assembly were released it would be manually embraced by a developer on the project that needed it. They could then test it, accept it, and place it into their build process. Obviously if that assembly changes on a daily basis some automation may be required.
Should I use the subversion 1.6 feature of svn:externals to individual files? No. I prefer to keep a project/solution as a self contained entity. Having tenticals spread out all of the place makes dependencies more painful. Keep silos as hard as possible...bring new things in as manual as possible...or as manual as the frequency that things change will allow.
我有类似的需求，并在 TortoiseSVN 的文档中找到了一个简短而甜蜜的答案：
http://tortoisesvn.net/docs/nightly/TortoiseSVN_en/tsvn-howto-common-projects.html
I had a similar need and found a short-and-sweet answer in TortoiseSVN's documentation :
http://tortoisesvn.net/docs/nightly/TortoiseSVN_en/tsvn-howto-common-projects.html