你如何组织你的版本控制库？

2018-06-13 03:29:46

首先，我知道这个：你将如何为内部软件项目组织一个Subversion仓库？接下来，真正的问题是：我的团队正在重建我们的存储库，并且正在寻找关于如何组织它的提示。（在这种情况下是SVN）。这是我们想出的。我们有一个存储库，多个项目和多个svn：外部交叉引用

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

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

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

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

如果你按照我的建议（我有多年），你将能够：

- 将每个项目放在源代码管理的任何位置，只要你保留项目根目录下的结构

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

- 只要你有权访问它的二进制依赖项（本地“库”和“输出”目录），就可以完全独立地构建每个项目。

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

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

- 避免使用生成的文件或库混淆你的源代码控制库

我推荐（这里是牛肉）：

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

将每个项目组织为具有单个根的目录树。

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

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

使每个项目构建脚本引用其来自单个本地共享“库”目录的外部（第三方）依赖项，每个这样的二进制文件完全由版本标识： %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%ToolA1.2.3.4 ， %DirToolRoot%ToolB5.6.7.8 。

通过相对于项目根目录的绝对路径使每个项目构建脚本参考源内容： ${project.base.dir}/src ， ${project.base.dir}/tst （语法因构建工具而异）。

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

切勿让项目构建脚本使用像.somedirshere或..somemoredirs这样的相对路径引用ANYING，总是使用绝对路径。

切勿允许项目构建脚本使用没有可配置根目录的绝对路径（如C:somedirshere或serversharemorestuffthere引用ANYING。

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

尝试最小化您必须创建以配置每台计算机的环境变量的数量。

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

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

要求每个项目构建脚本检查它的每个环境变量，如果没有定义它们，则用一个有意义的消息中止。

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

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

如果使用IDE，则可以生成任何项目控制文件，但不要将它们提交到源代码管理（包括Visual Studio项目文件）。

建立一个包含所有外部库和工具的官方副本的服务器，将其复制/安装在开发人员工作站上并构建机器。备份它，连同你的源代码控制库。

用NO开发工具建立一个持续集成服务器（构建机器）。

考虑一个管理外部库和可交付成果的工具，比如Ivy（与Ant一起使用）。

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

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

有关Visual Studio解决方案的其他说明：请勿将它们放在源代码管理中！采用这种方法，您根本不需要它们，或者可以生成它们（就像Visual Studio项目文件一样）。但是，我发现最好将解决方案文件留给单个开发人员，以便他们认为合适（但未签入到源代码管理）创建/使用。我在我的工作站上保存了一个Rob.sln文件，从中我引用了我当前的项目。由于我的项目都是独立的，我可以随意添加/删除项目（这意味着没有基于项目的依赖项引用）。

请不要使用Subversion外部程序（或其他工具中的类似程序），它们是反模式的，因此是不必要的。

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

@VonC：当你的构建脚本崩溃时，你不希望随时使用“ant.jar”而不是“ant-abcdjar”工作，因为你不知不觉地使用不兼容的Ant版本运行它。这在Ant 1.6.5和1.7.0之间特别常见。一般来说，你总是想知道每个组件的特定版本正在被使用，包括你的平台（Java ABCD）和你的构建工具（Ant EFGH）。否则，您最终会遇到一个错误，您的第一个BIG问题将会跟踪您所涉及的各种组件的版本。预先解决这个问题更好。

我相信，使用Subversion的实用版本控制拥有组织仓库所需的一切。

我们已经设置了几乎完全符合您发布的内容。我们使用一般形式：

Project1
   Development (for active dev - what you've called "Trunk", containing everything about a project)
   Branches (For older, still-evolving supported branches of the code)
       Version1
       Version1.1
       Version2
   Documentation (For any accompanying documents that aren't version-specific

虽然我认为它不如你的例子那么完整，但它对我们来说很好，并且让我们保持独立。我喜欢每个用户都有一个“Thrash”文件夹的想法 - 目前，这些类型的项目不会在Source控制中结束，我一直认为他们应该这样做。

链接地址: http://www.djcxy.com/p/37513.html

上一篇: How do you organize your version control repository?

下一篇: Storing 2 same id of post table with different language into database