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

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上工作的开发人员只需要检查解决方案3(而不是解决方案1),并且可以将解决方案签出到任何目录,即工作目录不需要固定的结构.

Answer 1

呵呵,这可能不是很有帮助,但是......都没有.:)

我会trunk处于最顶层,项目和解决方案在平面结构中彼此并排放置.然后,我将使用svn:externals解决方案目录上的属性将适当的项目提取到每个开发人员的工作副本中的正确位置.

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

此外,这种具有单个主干的方法使得标记或分支整个仓库变得更加容易,如果您需要这样做的话.