SVN Visual Studio存储库的工作目录结构

我刚刚在我们公司为我们的Visual Studio项目引入了SVN，并创建了如下所示的存储库（“解决方案”是Visual Studio解决方案，包含1..n个项目）：SVN Visual Studio存储库的工作目录结构

/solution1/trunk/projectA/... 
       /projectB/... 
/solution2/trunk/projectC/... 
/customerX/solution3/trunk/projectD/... 
      /solution4/trunk/projectE/... 
          /projectF/...

现在，我有两个选择构建本地工作目录：

选项A：让每一个单独的解决方案使用AnkhSVN的用户结账，导致结构是这样的：

/solution1/projectA/... 
      /projectB/... 
/solution2/projectC/... 
/solution3/projectD/... 
/solution4/projectE/... 
      /projectF/...

或此，如果我告诉用户手动创建一个子目录customerX：

/solution1/projectA/... 
      /projectB/... 
/solution2/projectC/... 
/customerX/solution3/projectD/... 
/customerX/solution4/projectE/... 
        /projectF/...

优势：用户可以只检出，他真正需要的解决方案。缺点：每个解决方案都需要单独检查/更新。

选项B：告诉用户结帐使用TortoiseSVN是整个仓库，导致这是完全一样的存储库的结构：

/solution1/trunk/projectA/... 
       /projectB/... 
/solution2/trunk/projectC/... 
/customerX/solution3/trunk/projectD/... 
      /solution4/trunk/projectE/... 
          /projectF/...

优势：它很容易为“SVN更新一切”。缺点：用户还拥有所有分支机构和标签的本地副本。

问题：由于一些项目的解决方案（比方说，例如，该了projectA是也使用solution3库），我们需要修复一个目录结构，以确保共享的相对路径在解决方案文件中是正确的。你推荐哪个选项，为什么？

编辑：感谢您的所有优秀的答案，特别是提svn:externals和强调一个好的库设计的重要性。我结束了更新我的库结构：

/trunk/solution1/projectA/... 
       /projectB/... 
     /solution2/projectC/... 
     /customerX/solution3/projectD/... 
          -svn:external to projectA 
       /solution4/projectE/... 
          /projectF/...

从而确保工作solution3 开发商只需要检查solution3（而不是解决方法1）和解决方案可以签出到任何目录即，工作目录不需要固定的结构。

来源

2009-11-02 Heinzi

好的问题，顺便说一句... – David 2009-11-02 15:38:01

呵呵，这可能不是非常有帮助的，但是......都不是。:)

我会有trunk在最顶层，项目和解决方案在之下组织在一起，在一个扁平结构彼此并排。然后，我将使用解决方案目录中的svn:externals属性将适当的项目引入每个开发人员工作副本中的正确位置。

我整理东西这种方式的原因是，它给你要从你的选项A和您的选择B.好处所以，如果开发商只是想看看一个单一的解决方案，他们可以自由地这样做。同样，如果他们宁愿这样做，他们也可以检查整个行李箱（并且他们能够在没有获得标签和分支的情况下这样做）。

此外，其单干线的这一做法使得它容易得多标签或分支整个回购，如果有的话，你需要做的。

来源

2009-11-02 15:24:26

+1。我没有使用svn：externals属性。 +1是给了我一些新的东西来探索那看起来很有前景的东西，它可能比我自己的解决方案更好。 – David 2009-11-02 15:59:06

树干在最高层...有趣的想法。我必须考虑这一点。 – Heinzi 2009-11-02 15:59:29

这与我们使用的结构相同。我不得不考虑svn：externals属性，因为我不熟悉它。 – 2009-11-02 16:08:15

对于它的价值，我们使用选项B.

我们也用龟SVN，而不是安赫SVN，因为我们有我们的资源库的结构好一点的灵活性，如果它不依赖于相同的目录结构Visual Studio期望。

我最初严厉地反对这个，因为我喜欢和TFS一起使用IDE集成，但在使用它几天之后，我被卖掉了，更大的灵活性的交易比以前更重要的数千倍与IDE的集成。

编辑 - 添加

另外值得一提的是切换到我们目前的流程之前，我们映射出我们究竟是如何想打好我们所有的源代码控制的。我们花了几个星期的时间准确计划它，在开关切换之前对它进行分析，但它在易用性和维护上得到了回报。

我们有一个像整体结构如下：

\内部Web应用程序

\互联网Web Apps的

\企业的WinForms应用

\企业寡妇服务

\ Retail Location WinForms Apps

\零售定位服务

\共享

\跨平台解决方案的文件。

每个主文件夹都包含许多不同的项目和解决方案。这些每个都有自己的分支，标签和中继线。因此，例如，如果我们有一个网上商店取景器，它可能在

\Internet\<our company name>.com\Store Finder\Trunk

这样做的重要组成部分，是共享，因为这包含了在所有其他分支使用的代码。具有IDE集成功能的原因不适用于我们，因为我们需要根级别的解决方案来实现此目的。相反，我们有适当的Sln文件，因为我们都有完整的存储库副本，所以我们可以确保\ Shared目录中任何项目的相对路径在所有开发人员的PC上都是相同的。

我提供了上述内容，而不是告诉你如何构造你的代码，只是为了给你提供一些想法，并强调在继续之前彻底规划它的重要性。

你需要花一些时间来问一些问题，比如“如果我像Y一样布置它，我可以做X吗？”。你的情况对你的团队和公司来说是独一无二的。

来源

2009-11-02 15:16:41 David

感谢您的详细解释！ – Heinzi 2009-11-02 16:02:10

选项A - 您不希望每次都拉动整个存储库（所有标签和分支），它会鼓励用户将整个存储库视为一个单一的实体，你希望他们在解决方案和标签/分支方面进行思考。

您通过在适当解决方案的“根”中引用它们作为外部对象来解决共享项目。这意味着你可能有多个相同的项目在你的硬盘上出现，但这是可管理的。

还有更多的蝇头位上这里的主题： HowTo: Reference external SLN files with TeamCity

来源

2009-11-02 15:24:25 Murph

我会使用扁平的目录结构，并使用svn:externals场所在包括共享项目的强烈第二菲尔摊位溶液。

主要的原因是，这给了你自由去耦不同使用共享项目客户项目如何，如图书馆，被更新。使用您提出的结构，所有其他客户端项目使用的共享库项目只有一个副本：因此，所有使用共享项目的项目都必须看到相同的版本。这并不总是可取的。

有时，变化到共享库将需要使用该库在客户端代码的相应变化。根据你提出的结构，这种改变将要求你立即更新图书馆的所有客户项目，或者承认许多客户项目可能会被打破。

对于使用库的每个客户端项目使用svn:externals意味着每个客户端都将拥有其工作副本中的该库副本（但磁盘空间很便宜）。但是，存储库中仍然有一个库项目的副本（客户端项目只是引用它的不同版本），因此特定的客户端项目可以继续使用旧版本的共享库，或者可以更新更新svn:externals属性），以使用更新的版本

总结：

对你提出的布局：提交更改库项目立即改变所有使用该库项目的所有客户端的项目得到更新图书馆，他们是否希望他们还是没有。

随着svn:externals，提交更改库项目只影响溴化锂ary项目。每个客户端项目都需要额外的提交来更新svn:externals属性，以引用该库的较新版本（可以将其与客户端项目代码的对应更改一起提交）。所有客户项目都可以更新图书馆，但只有在他们明确要求时才能获得。

来源

2009-11-02 16:21:19

SVN Visual Studio存储库的工作目录结构

回答

相关问题