多个SVN存储库或单个公司存储库

Question

我们是否应该为所有公司提供一个单独的存储库,其中包含许多开发项目或每个项目的存储库？关于经验/最佳实践的任何想法？

Answer 1

我发现有一个Subversion存储库可以帮助:

1. 透明度:更容易跟踪发生的事情,甚至在您可能没有直接参与的项目中查找代码.
2. 维护:没有必要在每次创建新项目时创建存储库,并且可以删除整个项目而不必担心会丢失Subversion中的记录.
3. 维护:只需备份一个存储库.

编辑: 其他原因:

• 全局修订ID - 通过将修订ID设为全局,它是:
  1. 更容易沟通(例如,在代码审查请求中,只需指定修订ID,而无需指定哪个项目).
  2. 当项目彼此依赖时,更容易保证原子性.
  3. 更容易看到提交到不同项目的顺序.

Answer 2

我个人更喜欢每个项目单独的存储库.有几个原因:

1. 修订号.每个项目存储库都有单独的修订顺序.

2. 粒度.对于每个项目的存储库,您无法提交具有相同版本号的不同项目.我认为这更有利,而有人会说这是一个缺陷.

3. 存储库大小.你的项目有多大？它是否在源代码管理下有二进制文件？我打赌它有.因此,大小很重要 - 二进制文件的每个版本都会增加存储库的大小.最终它变得笨拙而且很难支持.应支持细粒度的二进制文件存储策略,并提供其他管理.至于我,我仍然无法找到如何从存储库中完全删除二进制文件(由一些愚蠢的用户提交)及其内容历史记录.使用每个项目的存储库会更容易.

4. 内部存储库组织.我更喜欢细粒度,非常有组织,自包含,结构化的存储库.有一个图表说明了存储库维护过程的一般(理想)方法.我想你会同意使用'一个回购'方法中的所有项目是不可能的.例如,我的初始存储库结构(每个项目存储库应该具有)是:

   /project
       /trunk
       /tags
           /builds
               /PA
               /A
               /B
           /releases
               /AR
               /BR
               /RC
               /ST
       /branches
           /experimental
           /maintenance
               /versions
               /platforms
           /releases
   

5. 回购管理."每个项目的存储库"在用户访问配置方面具有更多可能性.但它更复杂.但也有一个有用的功能:您可以配置存储库以使用相同的配置文件

6. 回购支持.我更喜欢单独备份存储库.有人说,在这种情况下,不可能将信息从一个仓库合并到另一个仓库.为什么你需要那个呢？需要这种合并的情况表明,源控制的初始方法是错误的.项目的演变假设后续项目分离为子模块,而不是其他方式.我知道有办法做到这一点.

7. svn:externals."每个项目的存储库"方法鼓励使用svn:externals.当通过软链接建立项目和子模块之间的依赖关系时,这是一个健康的情况,svn:externals是.

   结论.如果要保持源代码控制简单,请使用一个存储库.如果要进行软件配置管理:

   1. 使用'每个项目的存储库'方法
   2. 引入软件配置管理器的单独角色并为其分配团队成员
   3. 雇用好管理员,谁可以应付所有颠覆技巧:)

PS.顺便说一句,尽管我一直在使用SVN而且我喜欢它,"每个项目的存储库"方法是我从存储库组织的角度看DCVS系统更具吸引力的原因.在DCVS中,repo是默认的项目.甚至没有"单一与多重"可能的问题,这只是胡说八道.

Answer 3

我强烈建议不要在每个项目中使用存储库.在单个subversion存储库中,您可以移动和复制数据,它将保留其历史记录.如果您认为作为后端工具启动的某些代码正在合并到前端,并且这些代码位于不同的存储库中,那么这不是颠覆会知道任何操作的操作.就好像你从前端添加了一些东西.这也意味着如果您需要临时维护两个版本的相关代码,则无法进行合并.

您将注意到,svn书中的所有示例都假设所有内容都在一个存储库中.

还有一个单独的问题,即是使用/ trunk/project1,/ trunk/project2,/ branches/project1-r1还是使用/ project1/trunk,/ project1/branches/r1,/ project2/trunk.通常,第二个更容易跟踪.

不将所有内容放在一个存储库中的最佳理由是访问控制很难比存储库级别更精细.可能,是的,但不是那么容易.我们目前有两个主要的存储库:

• 用于所有软件开发的svn /代码,需要提交jira票证
• svn/ops用于任何配置,设置脚本,第三方焦油,无论如何,不​​需要jira

Answer 4

这将取决于您的应用程序/项目在组织中的相互依赖性,以及代码库的大小.因此,它归结为如何定义组织中的"项目".共享代码库,共享组件,共享团队,共享发布周期,都可能影响您的存储库的结构需求.

为简单起见,我将项目定义为具有独立的代码库,发布时间表和/或属于一个工具/应用程序.如果是这种情况,我更喜欢每个项目有一个存储库.通过这种方式,可以更自由地为每个项目定义和实施策略/访问限制.

如果我有一个随着时间的推移膨胀的单个存储库..我可能还需要担心工作区检出时间等,特别是如果项目的代码都是混合的.如果应用程序/工具/项目已完成/搁置/废弃/迁移,如果在项目级别存在分离,则可以对管理方面进行更多控制.

如果每个项目有一个存储库,那么根据其独特需求构建项目存储库也会更容易.每个项目可能都有特定需求,这可能会影响每个项目遵循的配置管理策略(分支,标记,命名约定,CI等).这并不是说你不能在单个存储库中完成所有这些文件夹.您可以.它只是让事情变得更简单,以便更清晰地分离 - 这就是全部.

您可能需要考虑所有这些因素,以便根据您的具体设置评估最终可能产生的管理开销.

这就是说,如果项目规模都很小,并且相互依赖,需要交叉引用,交叉跟踪,相互移动等等,那么每个存储库只需一个repo和一个文件夹就可以了.