svn - 您如何组织版本控制存储库？

Question

首先，我知道这个:How would you organize a Subversion repository for in house software projects?
接下来，实际问题:
我的团队正在重组我们的存储库，我正在寻找有关如何组织它的提示。 (在这种情况下是 SVN)。
这是我们想出的。我们有一个存储库、多个项目和多个 svn:externals 交叉引用

\commonTools /*tools used in all projects. Referenced in each project with svn:externals*/
   \NUnit.v2.4.8
   \NCover.v.1.5.8
   \<other similar tools>
\commonFiles /*settings strong name keys etc.*/
   \ReSharper.settings
   \VisualStudio.settings
\trash /*each member of the team has trash for samples, experiments etc*/
   \user1
   \user2
\projects
   \Solution1 /*Single actual project (Visual Studio Solution)*/
      \trunk
         \src
             \Project1 /*Each sub-project resulting in single .dll or .exe*/
             \Project2
         \lib
         \tools
         \tests
         \Solution1.sln
      \tags
      \branches
   \Solution2
      \trunk
         \src
             \Project3 /*Each sub-project resulting in single .dll or .exe*/
             \Project1 /*Project1 from Solution1 references with svn:externals*/
         \lib
         \tools
         \tests
         \Solution2.sln
      \tags
      \branches

清除词汇:解决方案意味着单个产品，项目是一个 Visual Studio 项目(导致单个 .dll 或单个 .exe)

这就是我们计划布局存储库的方式。主要问题是，我们有多个解决方案，但我们想在解决方案之间共享项目。
我们认为将这些共享项目移动到他们自己的解决方案中是没有意义的，相反我们决定使用 svn:externals 在解决方案之间共享项目。我们还希望将一组通用工具和第 3 方库保存在存储库中的一个位置，并在每个解决方案中使用 svn:externals 引用它们。

您如何看待这种布局？特别是关于 svn:externals 的使用。这不是一个理想的解决方案，但考虑到所有的利弊，这是我们能想到的最好的解决方案。你会怎么做？

Answer 1

如果您遵循我下面的建议(我多年来一直这样做)，您将能够:

-- 将每个项目放在源代码控制中的任何位置，只要您保留项目根目录下的结构即可

-- 在任何机器上的任何地方构建每个项目，风险最小，准备工作最少

-- 完全独立地构建每个项目，只要您可以访问其二进制依赖项(本地“库”和“输出”目录)

-- 构建和使用任意项目组合，因为它们是独立的

-- 构建和处理单个项目的多个副本/版本，因为它们是独立的

-- 避免用生成的文件或库弄乱你的源代码控制存储库

我推荐(这里是牛肉):

定义每个项目以生成单个主要交付物，例如 .DLL、.EXE 或 .JAR(Visual Studio 默认)。

将每个项目构建为具有单个根的目录树。

在其根目录中为每个项目创建一个自动构建脚本，该脚本将从头开始构建它，不依赖于 IDE(但不要阻止它在 IDE 中构建，如果可行)。

考虑将 nAnt 用于 Windows 上的 .NET 项目，或基于您的操作系统、目标平台等的类似项目。

使每个项目构建脚本从单个本地共享“库”目录中引用其外部(第 3 方)依赖项，每个此类二进制文件均由版本完全标识:%DirLibraryRoot%\ComponentA-1.2.3.4.dll , %DirLibraryRoot%\ComponentB-5.6.7.8.dll .

使每个项目构建脚本将主要交付物发布到单个本地共享“输出”目录:%DirOutputRoot%\ProjectA-9.10.11.12.dll , %DirOutputRoot%\ProjectB-13.14.15.16.exe .

使每个项目构建脚本通过“库”和“输出”目录中的可配置和完全版本化的绝对路径(见上文)引用其依赖项，没有其他地方。

永远不要让一个项目直接引用另一个项目或其任何内容——只允许引用“输出”目录中的主要交付物(见上文)。

使每个项目构建脚本通过可配置且完全版本化的绝对路径引用其所需的构建工具:%DirToolRoot%\ToolA\1.2.3.4 , %DirToolRoot%\ToolB\5.6.7.8 .

通过相对于项目根目录的绝对路径使每个项目构建脚本引用源内容:${project.base.dir}/src , ${project.base.dir}/tst (语法因构建工具而异)。

总是需要一个项目构建脚本来通过一个绝对的、可配置的路径(以可配置变量指定的目录为根)来引用每个文件或目录:${project.base.dir}/some/dirs或 ${env.Variable}/other/dir .

永远不要允许项目构建脚本使用相对路径(如 .\some\dirs\here)引用任何内容或 ..\some\more\dirs , 始终使用绝对路径。

永远不要允许项目构建脚本使用没有可配置根目录的绝对路径引用任何内容，例如 C:\some\dirs\here或 \\server\share\more\stuff\there .

对于项目构建脚本引用的每个可配置根目录，定义将用于这些引用的环境变量。

尽量减少您必须创建以配置每台机器的环境变量的数量。

在每台机器上，创建一个定义必要环境变量的 shell 脚本，该变量特定于该机器(并且可能特定于该用户，如果相关)。

不要将特定于机器的配置 shell 脚本放入源代码管理中；相反，对于每个项目，在项目根目录中提交一份脚本副本作为模板。

要求每个项目构建脚本检查其每个环境变量，如果未定义，则以有意义的消息中止。

要求每个项目构建脚本检查其每个依赖构建工具可执行文件、外部库文件和依赖项目可交付文件，如果这些文件不存在，则以有意义的消息中止。

抵制将任何生成的文件提交到源代码控制的诱惑——没有项目可交付成果、没有生成的源代码、没有生成的文档等。

如果您使用 IDE，请尽可能生成任何项目控制文件，并且不要将它们提交到源代码控制(这包括 Visual Studio 项目文件)。

建立一个带有所有外部库和工具的正式副本的服务器，以便在开发人员工作站和构建机器上复制/安装。备份它，以及您的源代码控制存储库。

建立一个没有任何开发工具的持续集成服务器(构建机器)。

考虑一个用于管理外部库和交付物的工具，例如 Ivy(与 Ant 一起使用)。

不要使用Maven——它最初会让你开心，最终会让你哭泣。

请注意，这些都不是 Subversion 所特有的，其中大部分对于针对任何操作系统、硬件、平台、语言等的项目都是通用的。我确实使用了一些特定于操作系统和工具的语法，但仅用于说明- - 我相信您会转换为您选择的操作系统或工具。

关于 Visual Studio 解决方案的附加说明:不要将它们置于源代码管理中!使用这种方法，您根本不需要它们，或者您可以生成它们(就像 Visual Studio 项目文件一样)。但是，我发现最好将解决方案文件留给单独的开发人员按照他们认为合适的方式创建/使用(但不 checkin 源代码管理)。我保留了一个 Rob.sln我工作站上的文件，我从中引用了我当前的项目。由于我的项目都是独立的，我可以随意添加/删除项目(这意味着没有基于项目的依赖引用)。

请不要使用 Subversion 外部工具(或其他工具中的类似工具)，它们是一种反模式，因此是不必要的。

当您实现持续集成时，甚至当您只想自动化发布过程时，请为其创建一个脚本。制作一个单独的 shell 脚本，它: 获取项目名称(如存储库中列出的)和标签名称的参数，在可配置的根目录中创建一个临时目录，检查给定项目名称和标签名称的源(通过构造适当的 URL(在 Subversion 的情况下)到该临时目录，执行一个干净的构建，运行测试并打包交付物。这个 shell 脚本应该适用于任何项目，并且应该作为“构建工具”项目的一部分 checkin 源代码管理。您的持续集成服务器可以使用此脚本作为构建项目的基础，或者它甚至可以提供它(但您仍然可能需要自己的)。

@VonC:在构建脚本中断时您被烧毁后，您不想一直使用“ant.jar”而不是“ant-a.b.c.d.jar”，因为您在不知不觉中使用了不兼容的 Ant 版本运行它。这在 Ant 1.6.5 和 1.7.0 之间尤为常见。概括地说，您总是想知道正在使用的每个组件的特定版本，包括您的平台 (Java A.B.C.D) 和您的构建工具 (Ant E.F.G.H)。否则，您最终会遇到一个错误，并且您的第一个大问题将是跟踪涉及的各种组件的版本。最好提前解决这个问题。