SVN项目结构

我们正在从VSS转向SVN并且正在讨论项目结构。我们正在讨论下面显示的两个建议。SVN项目结构

由于项目发布版本与标签绑定，开发人员只需对该标签执行更新即可开始工作，因此第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

来源

2011-01-07 user481779

感谢您的回复。对于＃2，我们如何将项目版本和它的依赖版本联系在一起？在创建标签的时间点＃1，您正在创建标签的项目，它的依赖关系被认为是兼容的。 – user481779

＃2你使用svn：externals。基本上，它是你的项目中的子目录，与特定的svn结帐相关联。对于＃1，当依赖关系想要与其中一个使用它的项目“失去同步”时，或者两个（或更多）项目无法在相同的特定版本的依赖关系上进行协调时，会遇到问题。 –

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

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

如果要将项目设置为组织中的可重用库，然后将它作为一个单独的项目完全使用，这样就不会引入不必要的协同依赖关系。而且，我会鼓励你的开发团队不要检查依赖并与之协作。相反，构建依赖关系并将它们用作二进制库。通过这种方式，检出项目的人将始终拥有应用程序所需的最新库依赖项。如果需要更新，那么您可以担心检查依赖关系并构建它。（或者甚至更好，必须向项目团队可以发布最新的库作为二进制文件的位置。）对项目的版本

更新和依赖 如果用＃2的路线走，并有单独的项目和依赖关系，你的版本控制变得非常简单。这是它如何工作的概述。

团队A正在Project1上工作。
B队正在研究Project1依赖的Dependency1。
每当团队B完成他们的工作，他们就构建了一个Dependency1（一个二进制 - 也许是一个DLL，或一个库，或沿着这些线）的版本。他们现在也可以标记他们的项目。二进制名称可能是：Dependency1-v1.0.0
团队A获取Dependency1-v1.0.0的二进制版本并将其包含在他们的项目中。（通常，二进制文件保存在/ lib文件夹或类似项目中的文件夹中。）
每当团队A完成工作时，他们都可以发布他们的项目并标记他们的项目。

需要注意的是，在任何时候，做A队退房源代码依赖关系1，并把它纳入自己的项目。这样可以使两个项目的开发保持分离，以便开发团队之间有自主权。团队A可以使用二进制文件，只要他们喜欢就可以。如果他们想要更新的版本，他们会从B队获得最新版本。

这个过程与您使用来自外部来源的库时所做的并无太大区别。你无法控制他们如何版本化他们的库，所以你只需要抓住你需要的项目并在需要时进行更新。您将二进制文件保存在您自己的项目结构中，以便始终可以依靠它。

来源

2011-01-07 20:01:39 JasCav

非常感谢JasCav。我在帖子中添加了一条评论，以了解将项目和Dependency版本捆绑在一起的过程。 – user481779

@ user481779 - 更新了我的答案。如果这可以帮助你，请确保你注册或接受答案。我注意到你现在的比例很低（25％）。如果人们知道你要奖励他们，你会得到更好的答案。 – JasCav

我会亲自去＃2。我在我以前的公司做过这件事，而且工作得很好。它隔离了每个项目，因此您可以轻松查看其分支和标记的历史记录，而无需额外的工作。只需签出一个项目并获取所有分支，标签和主干，在追踪本地差异时也是一项很好的功能。

来源

2011-01-07 19:58:41

非常感谢马克。我在帖子中添加了一条评论，以了解将项目和Dependency版本捆绑在一起的过程。 – user481779

-1

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

我使用下面的结构：

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

的第三方目录是用于非源代码依赖性诸如图书馆或API。

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

来源

2011-01-07 20:07:47 Derek

谢谢德里克。除了依赖于共享库之外，我们的项目与其他项目无关。 – user481779

-1

我的经验是它只是一个约定的问题。而且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图书网址是固定

来源

2011-01-07 20:24:50 Nishant

@downvoter请解释一下。这是一个关于约定的问题 - 不可能有正确或错误的答案。投票中没有任何意义。 – Nishant

去与＃2：

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

与必须参考其他项目，检查出部分上"SVN Externals"项目。这使您可以将依赖项的特定SVN修订版设置为另一个项目中使用的值。

来源

2011-01-07 20:36:29

我知道我迟到了......这是否意味着你在内部使用SVnExternals 'Project1-Trunk-whatever'链接到'Dependency1-trunk-whaterver'？ – BlueChippy

您有想在项目中引用其他源代码的想法;但是，还有其他解决方案。大多数IDE能够将源代码分发（通常是zip）附加到已编译的JAR。您可能希望仅将这两个项目分割开来，并用Maven或Ivy管理它们之间的相互依赖关系。经过一些设置后，它确实提供了不仅仅依赖管理。它提供了一个自动化的世界，能够以更少的人力完成更多的工作。 –

这篇文章的主要观点是，“每个项目一个仓库”比“一个包含依赖项的仓库”更受青睐，主要是因为它允许您在监视仓库时减少构建工作的范围。存储库更改触发器意味着构建该项目，并且不会构建任何不受此更改影响的项目。这意味着更少的测试（因为测试永远不会重新测试一个没有改变但重建过的库），减少编译时间，并且更好地将未来问题控制到更小的代码区域。 –

谢谢大家帮助我理解这个好多了！

@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个依赖项。

来源

2011-01-12 15:03:19 AnneTheAgile

这些用户建议每个团队都有一个存储库，而不是只保留一个存储库，如所有这些结构所示，在另一个帖子VSS to SVN - Repositories上。这样SVN修订号码只会在个人团队提交后才会增加。

有没有人试过这种方法？是否有额外的开销工作？

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

来源

2011-01-12 16:28:06 AnneTheAgile

SVN项目结构

回答

相关问题