Question

我刚刚在我们公司的Visual Studio项目中引入了SVN，并创建了一个类似于此的存储库（“解决方案”是Visual Studio解决方案，包含1..n个项目）：

/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是一个也被解决方案3使用的库），我们需要修复一个目录结构，以确保解决方案文件中的相对路径是正确的。你推荐哪个选项以及为什么？

编辑：感谢您提供的所有优秀答案，特别是提及svn:externals并强调良好的存储库设计的重要性。我最终更新了我的存储库结构：

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

确保只在<3> em 上工作的开发人员需要检查解决方案3（而不是解决方案1）和解决方案可以检出任何目录，即工作目录不需要固定的结构。

Answer 1

呵呵，这可能不是很有帮助，但是......都没有。：）

我会在最高级别trunk，项目和解决方案在下面以平面结构的方式组织在一起。然后，我将使用解决方案目录上的svn:externals属性将相应的项目提取到每个开发人员工作副本中的正确位置。

我以这种方式组织的原因是它为您提供了选项A和选项B的好处。因此，如果开发人员只想查看单个解决方案，他们可以自由地执行此操作。同样，他们也可以检查整个主干，如果他们宁愿那样做（而且他们能够这样做而不需要标签和分支）。

此外，这种拥有单个主干的方法可以更容易地标记或分支整个仓库，如果您需要这样做的话。

Answer 2

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

我们还使用Tortoise SVN而不是Ankh SVN，因为如果它与Visual Studio期望的相同目录结构没有关联，我们对存储库的结构有更好的灵活性。

我最初强烈反对这一点，因为我喜欢我与TFS的IDE集成，但在使用它几天后，我被卖掉了，更大的灵活性的折衷比数千倍重要。与IDE集成。

修改 - 添加

值得注意的是，在切换到我们当前的流程之前，我们确切地规划了我们想要布置所有源代码控制的方式。我们花了几个星期的时间来准确地计划它，在进行切换之前将其分析为死亡，但它在易用性和维护方面得到了回报。

我们有如下整体结构：

\内部网络应用

\ Internet Web Apps

\ Corporate WinForms Apps

\ Corporate Widows Services

\零售位置WinForms应用

\零售定位服务

\共享

\跨平台解决方案文件。

每个主文件夹都包含许多不同的项目和解决方案。每个都有自己的分支，标签和中继。例如，如果我们有一个Internet Store Finder，它可能在

中

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

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

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

你需要花些时间问一些问题，比如“如果我像Y一样躺着，我能做X吗？”。您的情况对您的团队和公司而言是独一无二的。

Answer 3

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

您通过在相应解决方案的“根”中将它们引用为外部来解决共享项目的问题。这意味着您可能在HDD上多次出现相同的项目，但这是可管理的。

这里有关于这个主题的更多内容： HowTo: Reference external SLN files with TeamCity

Answer 4

我强烈推崇使用平面目录结构并在include共享项目中使用svn:externals属性的Phil Booths解决方案。

主要原因是，这使您可以自由地分离使用共享项目（如库）的不同客户端项目的更新方式。使用您提出的结构，所有其他客户端项目只使用共享库项目的一个副本：因此使用共享项目的所有项目必须看到相同的版本。这并不总是可取的。

有时，对共享库的更改将需要使用该库对客户端代码进行相应更改。根据您提出的结构，这样的更改将要求您立即更新库的所有客户端项目，或者承认许多客户端项目可能已损坏。

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

总结：

在您建议的布局中：立即更改库项目会更改使用该库的所有项目。所有客户端项目都会获得库的更新，无论他们是否需要它们。

使用svn:externals，对库项目进行更改只会影响库项目。每个客户端项目都需要额外的提交来更新svn:externals属性以引用更新版本的库（可以与客户端项目代码的对应更改一起提交）。所有客户端项目都可以对库进行更新，但只有在明确要求时才能获取它们。

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

4 个答案: