Question

我的公司即将转向使用svn，我正在寻找有关存储库结构的建议。

我们目前有大约10个项目和一个内部通用软件存储库，其中一些项目使用，有些则没有。由于通用软件在内部进行了修改，因此它本身就是一个项目。因此，虽然这些项目是无关的，但它们可能共享相同的通用软件。

使用通用软件的项目总是引用基线版本，即在任何项目下都不会修改通用软件（除了通用软件项目本身）。

因此，每个项目的单独存储库是最好的，通用软件项目“标记”版本使用svn：externals挂钩？

任何建议表示赞赏。

Answer 1

我建议你按照http://svnbook.red-bean.com/en/1.7/svn.reposadmin.planning.html中的第一个例子将所有内容放在一个回购中。 COMMON将是所有其他项目中的一个项目。

然后将COMMON的发布标签复制到每个项目，反映每个项目当前使用的COMMON版本。

示例布局：

/common
  /branches
    /common_improvements1
    /common_improvements2
  /tags
    /common-1.0.0
    /common-1.0.1
  /trunk
/projA
  /branches
    /stable-1.0
      /common (=copy of /projA/trunk@oldrev =copy of /common/tags/common-1.0.0)
    /stable-2.0
      /common (=copy of /projA/trunk@somerev =copy of /common/tags/common-1.0.1)
    /projA_ongoing_fix_branch
  /tags
    /1.0.1
    /1.0.2
    /1.1.0
    /2.0.0
    /2.0.1
  /trunk
    /common (=copy of /common/tags/common-1.0.1)
/projB
  (similar structures)
/projC
  (similar structures)

优点：

COMMON和项目之间的轻松访问和可追溯性
如果有用，用户可以轻松地互动，测试和支持彼此的工作
COMMON发布标签的副本回答了这个问题：我们目前在这个项目中使用哪个版本的COMMON？

导入期间的可选步骤：

今天所有项目都有一个共同的布局，例如服务器或其他版本控制系统上的文件结构？如果是这样，我建议您：

将整个布局导入新存储库中的文件夹，例如/根/ old_layout
将项目文件和文件夹移动到svn repos

这样做的好处是修订日志回答了这个问题：我们之前的结构中这个文件在哪里？在向开发人员讲授新结构时，以及在布局更改后临时资源（例如顾问）回来时，这非常有用。

Answer 2

所有开发人员都会参与所有项目吗？或者每个开发人员只会在特定项目上工作吗？

如果前者我会考虑将每个项目作为一个分支（因为在分支之间切换比在存储库之间切换更容易）。您还可以非常轻松地为新项目创建新分支。

如果是后者那么单独的回购可能更清晰，更容易管理。

Answer 3

不要使用单独的存储库，将其全部集中在一起（SVN可以非常愉快地处理非常大的存储库）。这将为您提供共享公共代码和分支的好处。

无论如何，差异实际上只是顶层的额外“目录”。这样做的好处是维护更少，更容易访问。

SVN存储库结构

3 个答案: