组织解决方案，项目和SVN

Question

我想在目录结构方面帮助您在SVN中设置项目。我已经阅读了关于这个问题的几个答案，但由于我对此很陌生，其中大多数都很难理解。

我建立一个单一的库，在其上其他几个不同的项目依赖于：

我需要出口在MyLibrary的能力（头，只.LIB）很容易通过第三方

MyLibrary1

使用

• 取决于外部库，应该可以管理这些库的不同版本！

MyLibrary2

• 取决于外部库FMOD，GLEW，...

项目1，2，4，5，6 ...

• Depends中在MyLibrary1,2或两者上
• 每个项目可能需要多个平台的版本（osx，windows ...）

我想知道一个很好的方法来组织这个，请记住，我对此很新 - 一个更迂回的答案会有帮助。例如，如果您编写/ src之类的东西，请解释应该进入的内容！我可以猜到，但我不敢肯定=）

//////////////////////////////// ////////////////////////////////////////////////// //////////////////////////

//编辑

我不能把这个变成一个评论，所以这里有云： @JN，感谢您的回复广泛，我想澄清一些东西，我希望我明白你的意思正确：

root 
    library foo 
     /branches   // old versions of foo 
     /tags    // releases of foo 
     /trunk    // current version 
      /build   // stuff required by makefiles 
      /tools   // scripts to launch tests ect 
      /data   // test data needed when running 
      /output   // binaries, .exe files 
      /dependencies // libraries that foo needs 
       /lib name 
        include 
        lib 
      /docs   // documentation 
      /releases  // generated archives 
      /sample   // sample project that shows how to use foo 
      /source   // *.h, *.cpp 

    program bar 
     /branches   // old versions of bar 
     /tags    // releases of bar 
     /trunk    // current version 
      /build   // stuff required by makefiles 
      /tools   // scripts to launch tests ect 
      /data   // test data needed when running 
      /output   // binaries, .exe files 
      /dependencies // libraries that bar needs 
       /lib name 
        include 
        lib 
      /docs   // documentation 
      /releases  // generated archives 
      /sample   // sample project that shows how to use bar 
      /source   // *.h, *.cpp 

1）在哪里的*的.sln文件去？在/构建？

2）我是否需要将foo/source复制到bar/dependencies/foo/include？毕竟吧取决于foo

3）* .dll文件去哪里？如果foo依赖于dll文件，那么所有使用foo的程序都需要访问相同的dll文件。这应该进入root/dll吗？

Answer 1

您的问题有几个层次：如何组织一个项目源代码树，如何维护不同的项目，如何维护这些项目的依赖关系，如何维护每个项目的不同变体以及如何包装他们。

请记住，不管你做什么，你的项目最终都会变得足够大，使它不适应。在项目的整个生命周期中多次改变结构是正常的。当这种情况发生时，你会感觉到它不再适用：它通常是在设置困扰你的时候，而不是它的帮助。

---

1 - 维护每个项目的不同变种

还没有变异为每个项目，您不会维持parralel版本或分支机构解决几个变种。对于可用于所有变体的每个项目/库，有一个单一源树。不要管理不同的“操作系统”，管理不同的功能。也就是说，有像“支持posix套接字”或“支持用户界面”等变体。这意味着，如果有新的操作系统出现，那么您只需选择它支持的一组功能，而不是启动新版本。

当需要特定的代码时，创建一个接口（C++中的抽象类），并实现与之相关的行为。这将隔离有问题的代码，并有助于在将来添加新的变体。使用宏在编译时选择适当的宏。

---

2 - 维护每个项目

的依赖关系有一个特定的“依赖”文件夹中的每个子文件夹包含需要一个依赖一切（这是包括和子依赖）。在代码库不是太大的时候，你不必太在意自动确保所有的依赖关系都是相互兼容的，保存以备后用。

不要尝试从svn层次结构中较高的根位置合并依赖项。正式将每个新版本交付给需要它的团队，由他们自行更新自己的SVN部分。

不要尝试一次使用同一依赖项的多个版本。那会很糟糕。如果你真的需要（，但尽量避免它，尽可能多的），分支为每个版本的项目。

---

3 - 维护不同项目

我建议保持每个项目独立存储库（SVN的他们仍然可能是相同的回购，但在分开的文件夹）。分支和标签应该专门针对一个项目，而不是全部。尽量限制分支的数量，他们不能解决问题（即使使用git）。使用分支机制时，您必须并行维护不同的时间版本（而非变体），并在实际执行之前尽可能多地进行反击，每个人都将从使用较新的代码中受益。

这将允许强加安全限制（不确定如果可行与香草SVN，但有一些免费的服务器支持它）。

我建议发送电子邮件通知，只要有人向潜在感兴趣的所有人提交项目。

---

4 - 项目源代码树组织

每个项目应具备以下SVN结构：

• 干线（当前版本）
• 分公司（旧版本，沿用至今）
• 标签（发布，用于在需要补丁时不需要考虑太多而创建分支） 当项目变得更大时r，在子文件夹（例如分支机构/ V1.0/V1.1和分支机构/ V2.0/V2.1）中组织分支机构和标签。

具有以下子文件夹的根文件夹：

• 编译系统
• 工具（由您的makefile文件或其他需要的东西）（如果有的话（其中一些可能由VC自己创建） ，像XSLT工具或SOAP编译器，脚本启动测试）
• 数据（你需要在运行测试数据）
• 输出（其中构建系统把二进制文件）
• 温度输出（由编译创建的临时文件，可选）
• 依赖
• 文件（如有）或生成的文档）
• 发布（生成的档案见后）
• 样品（一个小项目演示如何使用项目/库）
• 源（我不喜欢拆分头和.cpp，但是这是我的方式）
  • 避免子文件夹的层次太多，很难查找树，名单更容易
  • 定义适当的每个文件夹的构建顺序（没有那么必要的VC，但仍然）
  • 我把我的命名空间符合我的文件夹名称（旧Java的习惯，但工程）
  • 明确规定需要在“公共”部分出口
  • 如果项目足够大，可以容纳多个二进制文件/ DLL的每一个都应该有自己的文件夹

不承诺你产生任何的二进制文件，只有释放。二进制文件喜欢相互冲突并给团队中的其他人造成痛苦。

---

5 - 包装项目

首先，要确保包含SVN版本和日期的文本文件，有一个自动化的方式来做到这一点与自动道具。

你应该有一个脚本来产生版本（如果时间允许的话）。它会检查所有提交的内容，生成一个新的版本号....创建一个zip/tar。gz归档您必须提交/归档，其名称包含SVN修订版，分支和当前日期（格式应该在项目间标准化）。归档文件应该具有运行应用程序所需的所有内容/在文件结构中使用库。创建一个标签，以便从紧急情况修复开始。