SVN布局——最佳实践
在 CVS 中，我们的项目中有多个目录。 有一个夜间构建必须从同一 CVS 项目中的不同目录中提取内容才能构建夜间构建。 所以我应该牢记这一点，如果我们迁移到 SVN，我必须修改构建脚本以从不同的存储库中检查内容。
我阅读了相关的 SVN QA，但我有自己的问题需要答案。
我可以这样做：
/trunk
/tags
/branches
/3rdparty
我们开发的所有内容都来自 /trunk，我们不更改的任何 3rdparty 都会转到 /3rdparty。
一切都好，现在每晚构建脚本必须标记主干，签出标记，将所需的 3rdparty 内容检出到正确的目录中，然后开始构建过程。
构建结果（编译后的内容）可以在 NFS 挂载上保留一段时间，以便集成团队可以回溯 2 周并重新创建问题。
我所有的基地都被覆盖了吗？
In CVS we have on project with multiple directories in there.
There is a nightly build that has to pull in stuff from different directory in the same CVS project in order to build the nightly build. So I should have that in mind and I have to modify the build script to check things out from different repositories if we move to SVN.
I read the related SVN QA, but I have my own question that I need the answer for.
I can do:
/trunk
/tags
/branches
/3rdparty
Where everything we develop comes out of the /trunk and any 3rdparty that we don't change goes to /3rdparty.
All good, now the nightly build script has to tag the trunk, checkout the tag, check out the required 3rdparty stuff into proper directories, then start the build process.
The build result (compiled stuff) can stay on NFS mount for some period so Integration team can go back 2 weeks and recreate problems.
Are all my bases covered?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
为什么不把第三者移到后备箱呢？ 当您的每个分支时，第 3 方的副本都会进入分支。 显然，您不会更改分支中的第 3 方内容，因为您的分支已根据现有的第 3 方内容进行编码。
我不太确定是否要标记您正在谈论的内容。 你说的是版本号吗？ 如果是版本号，则通过脚本传递该版本号并标记构建。
Why don't you move the 3rd party into trunk? when every you branch a copy of 3rd party goes into branch. And obviously you wont change 3rd party stuff in branche because your branch has coded based on the existing 3rd party stuff.
I'm not so sure about tagging what you are talking about. Is that the version number you mean? If it is version number pass that thru script and label the build.
如果“多个目录”是您想要独立版本化的单独组件，那么您应该将每个组件放在自己的存储库中，以便可以单独标记它们。 但是，如果这都是一个独立的项目（即，如果您通常将所有组件标记和分支在一起），那么您可能可以将所有代码放在同一个存储库中。
您应该考虑为第三方使用外部文物。
If the "multiple directories" are separate components that you want to version independently, then you should have each in its own repository so that they can be tagged separately. But if this is all a single self-contained project (i.e. if you will generally be tagging and branching all components together), then you can probably put all of the code in the same repository.
You should consider using externals for the third-party artifacts.
我的脚本检查主干，修改文件（调整 AssemblyInfo.cs 文件中的版本号等），然后对其进行标记。 如果您不需要以任何方式修改文件，那么首先标记也是不错的选择。
除此之外，你的设置至少对我来说听起来不错。
My script checks out trunk, modifies the files (adjusts version numbers in AssemblyInfo.cs files, etc.), then tags that. If you don't need to modify the files in any way, then tagging first would be good as well.
Other than that, your setup sounds good to me at least.
SVN 红皮书此处包含大量有关不同项目类型的布局以及如何管理它们的信息。
您可能还想使用钩子/触发器/外部从名为“第三方”的独立存储库中提取数据。 因此，当开发人员检查一个存储库时，他也会获得第三部分。 有很多方法可以分离关注点，但可以从组件中提供统一的存储库。
祝你好运
The SVN redbook here includes alot of information on layouts for different project types and how to manage them.
You may also want to use hooks/triggers/externals to pull in data from an independent repo called '3rd party'. So when a developer checks out one repo, he gets the 3rd part too. There are tons of ways to separate concerns but present a unified repo from component ones.
Good luck
可能值得使用 hudson 等构建引擎或巡航控制。
工作流程略有不同 - 标签是在构建后创建的，但您可以获得额外的模块来对此进行一些控制。
重点是，所有的开发工作都为您完成，您将获得一个适合夜间构建的不错的框架，并且您将获得一个漂亮的 Web 界面来控制和监视一切。
就我个人而言，我会在 trunk 上放置一些外部定义，以将适当的第 3 方库引入到适当的位置。 这样，当您更改第 3 方库版本时，您可以对主干进行更改，而不必修改构建脚本。
这也意味着您只需检查适当的主干/标签/分支就可以构建旧版本。 请注意——只要在树干上做，散落各处可能会导致谋杀。
我还将存储库分层，有点像：
简单地因为这为您提供了在某个时候添加更多顶级项目的更多空间。 这样做可以让您完全独立地管理不同的项目 - 如果存在依赖关系，您仍然可以使用外部引用从一个项目到另一个项目的正确版本 - 这很好地阻止了一个项目中的更改默默地破坏/更改依赖项目。
也可以使用单独的存储库来完成此操作，这很好，但在这种情况下，我会从一开始就将单独的 3rdparty 部分放入单独的存储库中。
It might be worth making use of a build engine like hudson or cruise control.
The work flow is slightly different - tags are made after the build, but you can get extra modules that give you some control over that.
Point is, all the dev work is done for you, and you get a decent framework for your nightly builds, and you get a nice web interface to control and monitor everything.
Personally, I'd put some externals definitions on trunk to pull in the appropriate 3rd party libraries into the appropriate places. That way, when you change 3rd party library version, you make the changes to trunk and don't have to modify the build scripts.
It also means that you can build older versions just be checking out the appropriate trunk/tag/branch. Be warned - just do them on trunk, scattering them around can lead to murder.
I'd also layer the repo somewhat like:
Simply because this gives you more scope for adding more top level projects at some point. Doing this lets you manage different projects completely independently - and you can still use externals to reference the right versions from one to the other if there are dependencies - this nicely stops changes in one project silently breaking/changing dependant projects.
It's possible to do this using separate repos as well, which is fine, but in that case I'd put separate the 3rdparty section into a separate repo from the start.