我刚刚在我们公司为 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 checkout 整个存储库，从而得到与存储库完全相同的结构:
/solution1/trunk/projectA/...
/projectB/...
/solution2/trunk/projectC/...
/customerX/solution3/trunk/projectD/...
/solution4/trunk/projectE/...
/projectF/...
优点:“svn update everything”非常容易。缺点:用户还拥有所有分支和标签的本地副本。
<小时/>问题:由于某些项目在解决方案之间共享(比方说，projectA 是一个库，也被解决方案 3 使用)，我们需要修复一个目录结构，以确保解决方案文件中的相对路径是正确的。您推荐哪个选项？为什么？
<小时/>编辑:感谢您所有出色的回答，特别是提到 svn:externals 并强调良好的存储库设计的重要性。我最终更新了我的存储库结构:
/trunk/solution1/projectA/...
/projectB/...
/solution2/projectC/...
/customerX/solution3/projectD/...
-svn:external to projectA
/solution4/projectE/...
/projectF/...
这确保了处理解决方案 3 的开发人员仅需要 check out 解决方案 3(而不是解决方案 1)并且该解决方案可以 check out 到任何目录，即工作目录不需要固定的结构。
最佳答案
呵呵，这可能不是很有帮助，但是......都没有。 :)
我会将主干放在最顶层，项目和解决方案在其下面组织成一个扁平结构，彼此并排。然后，我将使用解决方案目录上的 svn:externals 属性将适当的项目拉入每个开发人员工作副本中的正确位置。
我以这种方式组织事情的原因是，它可以让您从选项 A 和选项 B 中受益。因此，如果开发人员只想检查单个解决方案，他们可以自由地这样做。同样，如果他们愿意的话，他们也可以检查整个主干(并且他们能够在不获取标签和分支的情况下这样做)。
此外，如果您需要这样做，这种使用单个主干的方法可以更轻松地标记或分支整个存储库。
关于visual-studio - SVN Visual Studio 存储库的工作目录结构，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1661845/