您如何组织版本控制存储库? [英] How do you organize your version control repository?

问题描述

首先，我知道这个:您将如何为内部软件项目组织 Subversion 存储库?接下来，实际问题:我的团队正在重组我们的存储库，我正在寻找有关如何组织它的提示.(在这种情况下是 SVN).这是我们想出的.我们有一个仓库，多个项目和多个 svn:externals 交叉引用

First, I know about this: How would you organize a Subversion repository for in house software projects? Next, the actual question: My team is restructuring our repository and I'm looking for hints on how to organize it. (SVN in this case). Here's what we came up with. We have one repository, multiple projects and multiple svn:externals cross-references

\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)

To clear the vocabulary: Solution means single product, Project is a Visual Studio Project (that results in a single .dll or single .exe)

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

That's how we plan to lay out the repository. The main issue is, that we have multiple Solutions, but we want to share Projects among Solutions. We thought that there is no point really in moving those shared Projects to their own Solutions, and instead we decided to use svn:externals to share Projects among Solutions. We also want to keep common set of tools and 3rd party libraries in one place in the repository, and them reference them in each Solution with svn:externals.

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

What do you think about this layout? Especially about the use of svn:externals. It's not an ideal solution, but considering all pros and cons, it's the best we could think of. How would YOU do it?

推荐答案

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

If you follow my recommendations below (I have for years), you will be able to:

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

-- put each project anywhere in source control, as long as you preserve the structure from the project root directory on down

-- 以最小的风险和最少的准备在任何机器上的任何位置构建每个项目

-- build each project anywhere on any machine, with minimum risk and minimum preparation

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

-- build each project completely stand-alone, as long as you have access to its binary dependencies (local "library" and "output" directories)

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

-- build and work with any combination of projects, since they are independent

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

-- build and work with multiple copies/versions of a single project, since they are independent

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

-- avoid cluttering your source control repository with generated files or libraries

我推荐(这里是牛肉):

I recommend (here's the beef):

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

1. Define each project to produce a single primary deliverable, such as an .DLL, .EXE, or .JAR (default with Visual Studio).

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

Structure each project as a directory tree with a single root.

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

Create an automated build script for each project in its root directory that will build it from scratch, with NO dependencies on an IDE (but don't prevent it from being built in the IDE, if feasible).

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

Consider nAnt for .NET projects on Windows, or something similar based on your OS, target platform, etc.

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

Make every project build script reference its external (3rd-party) dependencies from a single local shared "library" directory, with every such binary FULLY identified by version: %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.

Make every project build script publish the primary deliverable to a single local shared "output" directory: %DirOutputRoot%\ProjectA-9.10.11.12.dll, %DirOutputRoot%\ProjectB-13.14.15.16.exe.

让每个项目构建脚本通过库"和输出"目录中的可配置和完全版本化的绝对路径(见上文)引用其依赖项，而不是其他地方.

Make every project build script reference its dependencies via configurable and fully-versioned absolute paths (see above) in the "library" and "output" directories, AND NO WHERE ELSE.

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

NEVER let a project directly reference another project or any of its contents--only allow references to the primary deliverables in the "output" directory (see above).

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

Make every project build script reference its required build tools by a configurable and fully-versioned absolute path: %DirToolRoot%\ToolA\1.2.3.4, %DirToolRoot%\ToolB\5.6.7.8.

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

Make every project build script reference source content by an absolute path relative to the project root directory: ${project.base.dir}/src, ${project.base.dir}/tst (syntax varies by build tool).

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

ALWAYS require a project build script to reference EVERY file or directory via an absolute, configurable path (rooted at a directory specified by a configurable variable): ${project.base.dir}/some/dirs or ${env.Variable}/other/dir.

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

NEVER allow a project build script to reference ANYTHING with a relative path like .\some\dirs\here or ..\some\more\dirs, ALWAYS use absolute paths.

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

NEVER allow a project build script to reference ANYTHING using an absolute path that does not have a configurable root directory, like C:\some\dirs\here or \\server\share\more\stuff\there.

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

For each configurable root directory referenced by a project build script, define an environment variable that will be used for those references.

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

Attempt to minimize the number of environment variables you must create to configure each machine.

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

On each machine, create a shell script that defines the necessary environment variables, which is specific to THAT machine (and possibly specific to that user, if relevant).

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

Do NOT put the machine-specific configuration shell script into source control; instead, for each project, commit a copy of the script in the project root directory as a template.

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

REQUIRE each project build script to check each of its environment variables, and abort with a meaningful message if they are not defined.

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

REQUIRE each project build script to check each of its dependent build tool executables, external library files, and dependent project deliverable files, and abort with a meaningful message if those files do not exist.

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

RESIST the temptation to commit ANY generated files into source control--no project deliverables, no generated source, no generated docs, etc.

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

If you use an IDE, generate whatever project control files you can, and don't commit them to source control (this includes Visual Studio project files).

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

Establish a server with an official copy of all external libraries and tools, to be copied/installed on developer workstations and build machines. Back it up, along with your source control repository.

无需任何开发工具即可建立持续集成服务器(构建机器).

Establish a continuous integration server (build machine) with NO development tools whatsoever.

考虑使用一种工具来管理您的外部库和交付物，例如 Ivy(与 Ant 一起使用).

Consider a tool for managing your external libraries and deliverables, such as Ivy (used with Ant).

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

Do NOT use Maven--it will initially make you happy, and eventually make you cry.

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

Note that none of this is specific to Subversion, and most of it is generic to projects targeted to any OS, hardware, platform, language, etc. I did use a bit of OS- and tool-specific syntax, but only for illustration--I trust that you will translate to your OS or tool of choice.

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

Additional note regarding Visual Studio solutions: don't put them in source control! With this approach, you don't need them at all or you can generate them (just like the Visual Studio project files). However, I find it best to leave the solution files to individual developers to create/use as they see fit (but not checked in to source control). I keep a Rob.sln file on my workstation from which I reference my current project(s). Since my projects all stand-alone, I can add/remove projects at will (that means no project-based dependency references).

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

Please don't use Subversion externals (or similar in other tools), they are an anti-pattern and, therefore, unnecessary.

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

When you implement continuous integration, or even when you just want to automate the release process, create a script for it. Make a single shell script that: takes parameters of the project name (as listed in the repository) and tag name, creates a temporary directory within a configurable root directory, checks out the source for the given project name and tag name (by constructing the appropriate URL in the case of Subversion) to that temporary directory, performs a clean build that runs tests and packages the deliverable. This shell script should work on any project and should be checked into source control as part of your "build tools" project. Your continuous integration server can use this script as its foundation for building projects, or it might even provide it (but you still might want your own).

@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).否则，您最终会遇到一个错误，并且您的第一个大问题将是跟踪涉及的各种组件的版本.最好提前解决这个问题.

@VonC: You do NOT want to work at all times with "ant.jar" rather than "ant-a.b.c.d.jar" after you get burned when your build script breaks because you unknowingly ran it with an incompatible version of Ant. This is particularly common between Ant 1.6.5 and 1.7.0. Generalizing, you ALWAYS want to know what specific version of EVERY component is being used, including your platform (Java A.B.C.D) and your build tool (Ant E.F.G.H). Otherwise, you will eventually encounter a bug and your first BIG problem will be tracking down what versions of your various components are involved. It is simply better to solve that problem up front.

这篇关于您如何组织版本控制存储库?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！