这是我喜欢的一个：
- 的私人;所有当前的系统可交付成果
- <强>文档;组成产品的解决方案中的所有文档的汇总，输出将是来自Sandcastle的MSDN样式文档
- 的通用; Visual Studio SLN，包含所有其他解决方案中通用的所有项目。
- 工具; Visual Studio SLN，包含其输出为工具的所有项目。示例可能是在较大系统上执行一组管理任务的控制台应用程序
- 的开发;每个开发人员都有自己的文件夹，可以用来存储他们想要的东西
- 特定开发人员（1..n）;这包含此特定开发人员选择存储在源代码管理系统中的任何构建设置，脚本和工具（他们可以在此处执行任何操作）
- 特定的可交付解决方案（1..n）; Visual Studio SLN，包含特定主要可交付成果的所有项目
- 的通用;包含在当前解决方案中共享的Visual Studio项目的解决方案文件夹
- 的 UI ;包含定义用户体验的Visual Studio项目的解决方案文件夹
- 的数据层;包含定义数据访问层的Visual Studio项目的解决方案文件夹
- 的服务;包含定义Web服务的Visual Studio项目的解决方案文件夹
- 工具;包含Visual Studio项目的解决方案文件夹，该项目定义特定于此交付项的工具（可执行实用程序）
- 的测试;包含包含单元测试的Visual Studio项目的解决方案文件夹
- 公开;与系统关联的所有外部依赖项（例如，第三方库）
- <强>构建;包含与项目构建关联的代码的Visual Studio SLN，在我们的示例中主要是自定义MSBuild任务和Powershell脚本
- ：定位;每个成功构建的产品以及点发布
- 的调试;从每周构建和持续集成输出的所有调试版本。开发人员不手动管理此目录
- 内部版本号;与当前内部版本号对应的目录
- 解决方案输出;包含给定解决方案中每个项目的所有构建输出的目录
- 的推出;达到里程碑时手动输出的所有版本构建
- 内部版本号;与当前内部版本号对应的目录
- 解决方案输出;包含给定解决方案中每个项目的所有构建输出的目录
注意：所有解决方案都有一个Tests文件夹和单元测试项目。
一些想法：
- 树的根目录中的文件非常少。在大型团队中，设置权限，以便没有人可以在没有某种授权的情况下将新文件添加到树的根目录。
默认工作区将包含：
-
工具包含构建所需的所有可执行代码。运行单元测试，包括您的自定义工具和脚本（可能假设已在计算机上安装了Visual Studio和PowerShell）。
-
ReferencedAssemblies 包含您从其他地方获取的内容，包括您购买或下载的内容以及团队中的某些人编写但不属于此项目的内容。
- 如果可用，源代码也应该在这里，所以你可以自己服务。 （如果没有，你就会大肆宣传。）
-
来源 - 所有源代码，包括项目文件。
-
文档 - 未用作构建的一部分的项目，但对于开发工作的正常运行是必需的。
-
二进制文件 - 已发送给客户的位，包括.PDB和服务所需的其他工件。 （在小项目中，我为每个版本分配源代码，但通常标签/标签是更好的选择。）
在其他地方（例如$ / personal）为每个人提供了一个随心所欲的地方（$ / personal / USERNAME）。例如，我的副项目就在这里。