Question

我们正在从VSS迁移到SVN并正在讨论项目结构。我们正在讨论下面显示的两个提案。

没有。由于项目发布版本与a绑定，因此开发支持似乎更简单1 标签和开发人员只需要对该标签执行更新即可立即开始工作。

没有。 2确保所有项目和依赖关系都可以独立开发，但是构建特定的发布版本意味着知道项目的标签和所有这是依赖性。

两者之间是否有明显的比较效益？两个结构中的任何陷阱？或者有更好的结构吗？

1.
Development  
  + trunk  
    Project1  
    Project2  
    Dependency1  
    Dependency2  
    Dependency3  
  + branches  
  + tags  

2.
Project1  
  + trunk  
  + branches  
  + tags  
Project2  
  + trunk  
  + branches  
  + tags  
Dependency1  
  + trunk  
  + branches  
  + tags  
Dependency2  
  + trunk  
  + branches  
  + tags  
Dependency3  
  + trunk  
  + branches  
  + tags

Answer 1

选择＃2：

Project1  
  + trunk  
  + branches  
  + tags  
Project2  
  + trunk  
  + branches  
  + tags  
Dependency1  
  + trunk  
  + branches  
  + tags  
Dependency2  
  + trunk  
  + branches  
  + tags  
Dependency3  
  + trunk  
  + branches  
  + tags

对于必须引用其他项目的项目，请查看"SVN Externals"部分。这允许您将依赖项的特定SVN修订版设置为另一个项目中使用的值。

Answer 2

我个人选择＃2。我们在我以前的公司做过这件事并且效果很好。它隔离了每个项目，因此您可以轻松地查看其关于分支和标记的历史记录，而无需任何额外的工作。在本地跟踪差异时，只需检查项目并获取其所有分支，标记和主干的能力就是很好的。

Answer 3

一般来说，我建议让项目尽可能保持分离（第二种选择）。这通常会促进重用。（如果我只想要Dependency2，我不需要带一个完整的其他项目来实现它。）

但是，您必须明智地了解您的依赖关系究竟会做什么。例如，如果Dependency2 仅将成为Project1的依赖项，那么它应该只存在于Project1的源结构中。（注意：我并不是说有依赖的单独的分支和标签 - 我的意思是它在不同的包中，或者在Project1中的另一个子项目。）

如果您希望将项目作为组织内的可重用库，则将其作为一个单独的项目完全放置，这样您就不会引入不必要的共同依赖项。并且，我鼓励您的开发团队不要检查依赖项并与之一起工作。相反，构建依赖项并将它们用作二进制库。这样，无论谁签出项目来处理它都将始终具有应用程序所需的最新库依赖项。如果需要更新，那么您可以担心签出依赖关系并构建它。（或者，更好的是，项目团队可以将最新的库作为二进制文件发布。）

项目和依赖项版本控制的更新 如果您使用＃2路由，并且具有单独的Project和Dependencies，那么您的版本控制实际上变得非常简单。以下是它如何运作的概述。

A队正在开发Project1。

B队正在研究Project1所依赖的Dependency1。

每当B队完成他们的工作时，他们就会构建一个Dependency1（二进制文件 - 可能是DLL，或者某个库，或者其他类似的东西）。他们此时也可以标记他们的项目。二进制名称可以是：Dependency1-v1.0.0

Team A采用Dependency1-v1.0.0的二进制版本并将其包含在他们的项目中。（通常，二进制文件保存在/ lib文件夹中或类似项目中的内容。）

每当A队完成工作时，他们都可以发布他们的项目并标记他们的项目。

请注意，在任何时候，Team A 都会检出来自Dependency1的源代码并将其带入他们的项目中。这允许两个项目的开发保持独立，以便开发团队之间具有自主权。团队A可以根据自己的喜好使用二进制文件。如果他们想要更新版本，他们会从B队获得最新版本。

如果您使用来自外部源的库，那么此过程与您将要执行的操作没有太大区别。您无法控制他们对库的版本，因此您只需获取项目所需的内容并在需要时进行更新。您将二进制文件保存在自己的项目结构中，以便始终可以依赖它。

Answer 4

感谢大家帮助我更好地理解这一点！

@JasCav，我特别感谢您解释如何考虑特定依赖关系的“依赖性”。我有两个，所以我认为隐含的结构是：

Project1  
  + trunk  
       SubPrjFor_Prj1
       LibraryExternalRefs
           Dependency1_DLLOnly
           Dependency2_DLLOnly
           Dependency3_DLLOnly_NOT_SHARED_UsedOnlyByPrj1_ONLY_HERE
       LibraryWithSource
           Dependency4_UsedOnlyByPrj1_NOT_SHARED
                Source_SubFolder1
                Source_SubFolder2
  + branches  
  + tags  
Project2  
  + trunk  
       SubPrjFor_Prj2
       LibExternalRefs
           Dependency1_DLLOnly
  + branches  
  + tags  
Dependency1_UsedByBothPrj1Prj2  
  + trunk  
           Dependency1_DLLOnly
  + branches  
  + tags  
Dependency2_UsedByPrj1SoFar  
  + trunk  
           Dependency2_Source_SubPrj1
           Dependency2_Source_SubPrj2
  + branches  
  + tags

当然，我已经省略了树干/树枝的匹配结构。

ps @JasCav，对于没有投票给你，也没有把这个项目放在你的评论中，我深表歉意;我显然没有必要去做那些事情，这对我来说没什么意义。我认为登录会让我发表评论，从而跟踪感兴趣的Stackoverflow项目，但我猜不是。

编辑：修复格式并将示例扩展为4个依赖项。

Answer 5

而不是像所有这些结构所示，只在一个存储库中，在VSS to SVN - Repositories的另一个帖子中，用户建议每个团队拥有一个存储库。这样，SVN修订版号将仅在单个团队提交时才会增加。

你们有没有尝试过这种方法？是否涉及额外的间接费用？

我想用最少量的SVN管理工作保持代码库清洁，就像在我的情况下我可能会这样做:)。

Answer 6

如果所有项目都是同一个解决方案或产品的一部分，那么我会采用方法＃1。

我使用以下结构：

TRUNK
--Build
--Product
----Source
------Project1
------Project2
------Project3
----Test
--ThirdParty

ThirdParty目录用于非源代码依赖项，例如库或API。

我的指导植根于一个新的开发人员，他能够从Trunk获得最新信息并获得他们立即构建产品所需的一切（我指的是一切）。追逐参考文献是一个很容易避免的时间浪费。

Answer 7

我的经验只是一个常规问题。并且SVN Book也没有问题。

在其中一个项目中，团队正在使用ANT构建，并且更加强调平面结构。我们有方法＃2。使用一个主构建脚本。我正在努力做到这一点并没有问题。

当前项目涉及Maven构建，因此代码默认情况下具有＃1结构，其中包含一个父项，依赖项和模块化项目。在SVN中，我们遵循方法＃1。但是，如果一个全新的项目即将开始，我们将在布局中混合使用＃1和＃2。像这样：

    Project1
        trunk
            project1A
            project1B
            dependency1C
            dependency1D
        branches
        tags
    Project2
        trunk
            project2A
            dependency2B
        branches
        tags

总结一下，我想保持我的存储库在逻辑上是分开的。所以，回答你的问题 - 我更喜欢方法＃2。

编辑＃1：SVN-Book URL已修复

SVN项目结构

7 个答案: