我们有一个使用标准主干/分支/标签结构存储在 SVN 中的主要视觉工作室项目。然而，这个项目引用了这个结构之外的外部项目，所以当我们创建一个代码分支时，所有对外部项目的引用都失败了，因为它们是一个级别的。
即。 trunk/MyProjectCode 在分支后变成了 branches/MyFeatureBranch/MyProjectCode，因此由于这种额外的层次结构，任何对外部项目的引用都会失败。
以尽可能少的摩擦创建分支的最佳方法是什么？我可以编写一个修改所有项目引用的脚本，或者我可以更改我的本地代码布局，使分支实际上比主干低一级，因此新分支将位于同一级别。还有其他建议/最佳实践吗？
【问题讨论】：
标签： .net visual-studio svn
从 Subversion 签出时，您的工作目录不必反映与存储库中相同的目录深度。以命令行为例：
svn co svn://server/project/trunk 项目 svn co svn://server/project/branches/MyFeatureBranch project-feature
这样，您将拥有两个并排的目录，分别称为 project 和 project-feature。这应该避免不同目录深度和相对路径引用的问题。
【讨论】：
我们对与该产品相关的所有内容进行分支。因此，如果其中有 5 个项目，我们将所有 5 个项目分支，以确保我们拥有该分支将要使用的内容的完整副本。如果您遇到路径问题，您可能需要查看一个名为 Junction 的程序。
【讨论】：
我过去所做的是，对于开发许多项目和许多通用参考的开发商店，我将外部参考保存在共享位置。这可能是网络共享，或者是每个人在其硬盘驱动器上的约定（绝对）位置（结构类似于 C:\SharedLibs\Library\Version）。我们将 sharedlibs 保存在一个单独的 svn 存储库中，每个人都必须检查该 SharedLibs 文件夹，并设置我们对这个绝对路径的引用。
我应用的另一个策略是您在许多开源项目中也发现的策略：只需将引用存储在您的项目旁边。例如。你可以有一个带有子文件夹 src（用于源代码）和 lib（用于外部引用）的树干。这可能是更好的做法：构建项目（无论是主干还是分支）所需要做的就是检查它并运行构建工具。
另一个选项是使用 svn:externals 属性。使用此属性，您可以确保来自存储库中其他位置（或来自其他存储库）的文件与您的项目一起签出。根据经验，我不建议这样做，但这是一种选择。在 svn 书中阅读：http://svnbook.red-bean.com/en/1.5/svn.advanced.externals.html
【讨论】：
我们在这里遇到了同样的问题，我考虑过编辑 .sln 和 .csproj 文件，将相对路径替换为绝对路径。我有点担心这样做，因为 VS 维护这些文件，以及如何阻止它撤消此操作并在将来某个时候恢复到相对路径（例如，当开发人员保存项目并将其签入时）。
今天早上，我在通勤途中有一个“清晰的时刻”：即使我们将分支存储在专用的分支文件夹中，为什么我必须将其签出到一个文件夹中？
所以，而不是：
C:
|_ svnworkarea
|_ project
|_ branches
|_ project-feature
|_ source etc
|_ trunk
|_ source etc
我现在有：
C:
|_ svnworkarea
|_ project
|_ project-feature
|_ source etc
|_ trunk
|_ source etc
由于源文件夹现在处于同一级别，因此相对路径有效并且引用按预期加载。主干仍然是完全独立的，易于识别，而项目功能由有意义的文件夹名称标识，例如新UIBranch。
【讨论】：