代码之家  ›  专栏  ›  技术社区  ›  ScottE

建立Subversion知识库的建议

  •  1
  • ScottE  · 技术社区  · 15 年前

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

    我们几乎准备好把它投入全职使用。

    我们只构建小到Medum/大的Web应用程序,其中大多数共享相同的核心(但在lamp/win上有所不同),但在某种程度上是定制的。我们可能在存储库中有数百个项目。此外,我们通常为一个组织做多个项目。

    我们有灯光和窗户的开发人员。(我认为这使得问题与 Best practice for creating subversion repositories? )

    您对如何构建存储库有什么建议吗?

    6 回复  |  直到 15 年前
        1
  •  2
  •   Joe White    15 年前

    如何构建回购协议可能很大程度上取决于发行周期。当你做一个共同核心的新版本时,你会立刻向你的所有客户推出它吗?或者,当每个客户都需要新特性(因此,核心中也需要新特性)时,您会进行增量推广吗?

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

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

    这样做的缺点是,如果每个客户都有很多代码,那么您的签出将是巨大的,并且您必须签出所有可以做任何事情的代码(尽管SVN 1.6确实为您提供了签出树的一个子集的能力)。

    另一方面,如果不同的客户将按不同的时间表发布,那么您可能更希望为每个客户都有一个顶级目录。你还需要一个地方来保持你的共同核心。

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

    如果你这样做,你可能会想调查 svn:external 因此,只要检查客户1的源代码树,就可以得到一个公共核心的副本。但是,当您想要进行分支或标记时,这会导致一些问题。(这可能是选择第一个选项的原因。)

    如果还没有,请阅读“ Pragmatic Version Control Using Subversion “。他们有一些使用外部的例子,这可能有助于澄清您要使用的方案。

        2
  •  3
  •   Mike Caron    15 年前

    我认为一个单独的存储库(当然是备份的)和下面的单个项目目录就足够了:

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

    所以基础是核心代码,project1,project2,…projectn将包含基础的变化。当您签出Projectn时,您还将签出Base,并在Project1中具有指向Base的链接。

    这样做的另一种选择是简单地拥有一个包含核心的回购,并为每个变化创建一个分支。也就是说,如果核心是一个,那么很大的块,而您的变体实际上只是变体。

    这似乎更像是一个代码打包体系结构的问题,而不是版本控制结构的问题。

        3
  •  2
  •   Ratnesh Maurya    15 年前

    创建不同的项目作为不同的存储库(在同一台计算机上)。以便您可以分别控制每个项目的更改邮件列表:)

        4
  •  1
  •   B.E.    15 年前

    颠覆的伟大之处在于你一开始并不需要太在意。

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

    如果不是的话,以后就可以更换,不会有太多问题。

        5
  •  0
  •   Xetius    15 年前

    正确的答案是“任何最适合你的东西”。

    有些人会告诉你这种方式的优势,但在一天结束时,有Project->Trunk、Tags、Branches或Trunk、Tags、Branches->项目,或者如果你有一个Releases分支,或者如果你将这些分支重命名为任何其他名称,或者在其中有其他名称项,或者删除一些名称项都取决于ho你和你的同事在工作,什么最适合你的开发周期。

    但是,根据你所说的,我建议如下:

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

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

        6
  •  0
  •   aberrant80    15 年前

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

    假设你在问开发项目,你必须澄清你在做什么样的开发。不同的语言或项目类型通常导致不同的“标准”。

    继承自cvs的传统svn结构 trunk , branches tags 坐在主项目目录旁边。对于每个单独的项目目录都是重复的。

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

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

    这使得签出使用相同标记/分支标记的所有项目变得更容易。

    但它高度依赖于您的构建脚本以及您计划如何让开发人员或用户签出。对你的项目来说,最有逻辑性和效率的是什么。