设置 subversion 存储库的建议答案

【问题标题】：Suggestions for setting up a subversion repository设置 subversion 存储库的建议
【发布时间】：2010-11-09 08:57:03
【问题描述】：

我们的团队刚刚开始通过 SVN 使用源代码控制。我们目前正在使用一些测试存储库来适应这个过程。

我们几乎已准备好将其投入使用。

我们只构建小型到中型/大型网络应用程序，其中大部分共享相同的核心（但在 LAMP/Win 上不同），但以某种方式进行了定制。我们可能在存储库中有数百个项目。此外，我们通常为一个组织做多个项目。

我们有 LAMP 和 Windows 开发人员。（我认为这使问题与Best practice for creating subversion repositories? 有所不同）

您对如何构建存储库有任何建议吗？

【问题讨论】：

我实际上认为拥有 Linux 和 Windows 开发人员根本不会改变您链接到的问题。所有这些答案都适用。（这是源代码控制的要点之一——无论您的客户端操作系统是什么！）

标签： svn version-control

【解决方案1】：

我认为一个单独的存储库（当然是备份的）下面有单独的项目目录就足够了：

/usr/share/code_repository
   /base
      /trunk
      /branches
      /tags
   /project1
      /trunk
      /branches
      /tags
   /project2
      /trunk
      /branches
      /tags
   ...

所以 base 是核心代码，project1、project2、...projectN 将包含 base 的变体。当您签出 projectN 时，您还将签出 base 并在 Project1 中拥有指向 base 的链接。

以这种方式执行此操作的另一种方法是简单地拥有一个包含核心的 repo，并为每个变体创建一个分支。也就是说，如果核心是一个大块，而您的变体实际上只是变体。

这似乎更像是代码打包架构的问题，而不是版本控制结构的问题。

【讨论】：

这是我喜欢的方式，所以每个项目都有其单独的标签/分支。
SVN 是否维护每个存储库或每个项目的修订号？使用这种布局，project2 中的修订号不会更改 project1 中的最新编号吗？
组织成组织/项目有意义吗？正如我所说，我们有很多项目。
当然，但这有什么关系？
@matt svn 维护每个存储库的修订版

【解决方案2】：

您如何构建您的存储库可能很大程度上取决于发布周期。当你做一个新版本的公共核心时，你会立即将它推广给你的所有客户吗？或者，您是否会在每个客户需要新功能时（因此，需要核心中的新功能）逐步推出？

如果您在升级核心时向所有人推出，那么您可能需要一组分支/标签/主干：

branches/
tags/
trunk/
    core/
    customer1/
        project1/
        project2/
    customer2/
        project1/
        project2/

这样做的缺点是，如果每个客户都有很多代码，那么您的结帐会很庞大，并且您必须检查所有内容才能做任何事情（尽管 svn 1.6 确实为您提供了能力检查树的子集）。

另一方面，如果不同的客户将按不同的时间表发布，那么您可能更愿意为每个客户提供一个顶级目录。你还想找个地方来保存你的共同核心。

core/
    branches/
    tags/
    trunk/
customer1/
    branches/
    tags/
    trunk/

如果您这样做，您可能想要查看svn:external，以便在您查看customer1 的源代码树时获得公共核心的副本。但是，当您想要分支或标记时，这会导致一些问题。（这可能是首选第一个选项的原因。）

如果您还没有，请阅读“Pragmatic Version Control Using Subversion”。他们有一些使用外部的示例，这可能有助于阐明您要使用哪种方案。

【讨论】：

如果您在 svn:external 定义中使用明确的修订指示符，大多数 svn:external 问题都会消失。您的标签以这种方式保持稳定，升级到更新版本的核心需要显式提交以更改 svn:external 定义。

【解决方案3】：

将不同的项目创建为不同的存储库（在同一台机器上）。这样您就可以分别控制每个项目的更改邮件列表:)

【讨论】：

将其设置为多个存储库可能对 OP 来说是一个严重的限制，因为他们声明他们可能会有“数百个项目”。 IMO，从设置/维护/备份的角度维护单个存储库会更容易。如果您需要基于项目的自定义提交电子邮件，（同样是 IMO，）您应该相应地自定义您的 post-commit-send-email 脚本。 ....并将您的钩子脚本版本控制在存储库中！

【解决方案4】：

颠覆的伟大之处在于，你一开始就不必太在意。

因为您可以在存储库中移动文件和文件夹而不会丢失它们的历史记录，所以您可以从您认为正确的任何内容开始，看看它是否适合您。

如果不是，以后可以更改而不会出现太多问题。

【讨论】：

【解决方案5】：

正确的答案是“最适合你的”。

有些人会告诉你这种方式比那种方式的优势，但归根结底，有 project->{trunk, tags, branches} 或 {trunk, tags, branches}->project ，或者如果你有一个发布分支，或者如果你将它们重命名为其他任何东西，或者在那里有其他命名项目，或者删除一些命名项目，这完全取决于你和你的同事的工作方式以及最适合你的开发周期的东西。

但是，根据您的说法，我建议如下：

repository
    core
        trunk
        branches
        tags
    project1
        trunk
        branches
        tags
    project3
        trunk
        branches
        tags

这样做的好处是您可以将每个项目链接到不同版本的核心，这些版本位于 core/tags 文件夹内，同时仍允许开发核心。这只是我的建议。您的心态可能会有所不同

【讨论】：

你是对的，但我觉得 project->{trunk, tags, branches} 容易得多，否则你需要在无数其他项目中搜索你的标签/分支:-)
没错，老鼠，但你永远无法解释某些人的奇怪工作方式
aberrant80，我认为 Rats 在我为清晰起见进行编辑时发表了该评论，添加了最后一点，包括我使用的结构

【解决方案6】：

这是一个主观问题，因此您可能需要修改标签。

假设您询问的是开发项目，您必须明确说明您正在进行什么样的开发。不同的语言或项目类型通常会产生不同的“标准”。

继承自 CVS 的传统 SVN 结构是将 trunk、branches 和 tags 放在主项目目录中。这将为每个单独的项目目录复制。

对于相互依赖的项目，我个人更喜欢

root/somepath
  trunk
    myproject
  branches
    branch1
      myproject
    branch2
      myproject
  tags
    tag1
      myproject
    tag2
      myproject

这样可以更轻松地检查所有使用相同标签/分支标记的项目。

但这在很大程度上取决于您的构建脚本以及您计划如何让开发人员或用户签出。最好的是对您的项目合乎逻辑且高效的方法。

【讨论】：