Question

在开始之前，以下内容基于使用TortoiseSVN 1.6.x获得的知识以及以Visual Studio 2008为例的ASP.NET Web项目。

案例研究

说，在快乐的一天场景中，典型的subversion存储库结构可以类似于：

/trunk
    /Solution1
        /ProjectA
        /ProjectB
        /ProjectC
/tags
    /Solution1
        /version_1.0-rc
        /version_1.1
/branches
    /users
        /travis
            /Solution1
        /john
            /Solution1

Solution1是一个包含1到多个Visual Studio项目的Visual Studio解决方案。
用户正在开发自己的解决方案分支，偶尔会合并回主干。没有人直接在行李箱上工作。
只要有公开发布，就会从主干创建标记。

然而，在现实世界中，项目结构并不那么简单，因为许多Visual Studio项目在各种Visual Studio解决方案之间共享。存储库看起来更像：

/trunk
    /CandyLand
        /Candy.Web.Pages
        /Candy.Web.Services
        /Candy.Tests
    /LollyApp
        /Lolly.App.WinForm
        /Lolly.App.Services
        /Lolly.Tests
    /Fundamental
        /Fundamental.BusinessObjects
        /Fundamental.DataAccess
    /Components.ExternalLibraries
        /Subsonic-2.2
        /Moq-3.1
        /Lucene.NET-2.0

示例中有2个产品Candy和Lolly，共享组件（Visual Studio项目，DLL）分别位于Fundamental和Components.ExternalLibraries个文件夹中。

假设在trunk上工作，为了处理CandyLand Visual Studio解决方案，我需要从存储库以及所需组件中检出其文件，因此解决方案结构可能如下所示：

+ CandyLand
    + Candy.Web.Pages
    + Candy.Web.Services
    + Candy.Tests
    + Fundamental.BusinessObjects
    + Fundamental.DataAccess
    + Subsonic-2.2
    + Moq-3.1

将结帐和嵌套文件夹移到一起可能有点烦人，我们使用批处理脚本为我们执行此操作。

问题

我发现在这种情况下分支是不可能的，用户分支只包含分支解决方案中的项目，而不是共享项目。

与标记相同，我无法创建包含产品解决方案及其共享组件的修订快照的标记。

我走向错误的方向吗？我是否难以管理此存储库？

Answer 1

使用svn：externals在Candyland下包含文件夹。

在下面的示例中，*标记为外部：

+ CandyLand
    + Candy.Web.Pages
    + Candy.Web.Services
    + Candy.Tests
    * Fundamental.BusinessObjects
    * Fundamental.DataAccess
    * Subsonic-2.2
    * Moq-3.1

使用涉及多个项目的解决方案来管理SVN的最佳实践

1 个答案: