Question

我的一个网络应用程序在过去几个月中从单个项目文件增长到包含多个类库。 svn结构有点种植，看起来像这样：

repository-root
    site1
        trunk
        tags

    site2
        trunk
        tags

    library1
        trunk   
        tags
        ...

    library2
        trunk

现在开发正在加速，我希望有类似的东西

repository-root
    site1
        trunk
        tags
           release-20100922
             site1
             library1
             library2
             ...
           release-20110101
             ...

现在，由于Site1和Site2都引用了类库library1和library2，因此，重新组织文件夹结构的最佳方法是什么？

每个网站的代码都包含创建网站代码时相关类库的冻结副本，
每个站点仍然可以引用类库，而无需在每个站点的主干中单独创建副本

我可能只是想到这个错误。建议？

Answer 1

svn：外部作为模块化应用程序中的“软源控制链接”。

svn：externals可以帮助您避免一些手动任务，并清楚地了解什么是什么（以及在什么版本中）。

您有几种依赖图书馆的“独立”产品称为“网站”。您的产品和库也有相应的循环周期。为了提高稳定性，您可能不希望在任何地方使用中继库代码，因为它可能会破坏一个而不是多个站点。另一方面，在更敏捷的方法中，可能需要“早点休息，经常休息”。因此，选择在主线开发中使用的库代码版本将是一个优势。

此外，您的稳定/孵化分支（如果将来有任何分支）可能希望与库的一个特定版本同步，以便将增强的兼容性传输到结果标记中。

我会建议以下布局：

repository-root
    site1
        trunk (active development, unstable)
             mycode
             library1 -> external of "library1/tags/2.0"
        branches
            2-branch (maintenance, stable)
                mycode
                library1 -> external of "library/tags/1.0"
        tags
            2.0.0
                mycode
                library1 -> external of "library/tags/1.0"
            2.0.1
                mycode
                library1 -> external of "library/tags/1.0"
    library1
        trunk   
        tags
            1.0
            2.0
            ...

当你改变主意时，没有必要合并或移动arround库源代码，并决定“嘿，在我们的主干中使用新的2.0库1 API是件小事，也许我们将来应该使用主干。”

让我们想象一下“library1 1.0”中有一个错误，所以你发布了“library1 1.1”。您还需要为主应用程序创建一个新的错误修复版本并将其发布出去。所以你更新你的“site1 2.0”维护分支，测试并创建一个标签。

repository-root
    site1
        trunk (active development, unstable)
             mycode
             library1 -> external of "library1/tags/2.0"
        branches
            2-branch (maintenance, stable)
                mycode
                library1 -> external of "library/tags/1.1" (changed the property)
        tags
            2.0.0
                mycode
                library1 -> external of "library/tags/1.0"
            2.0.1
                mycode
                library1 -> external of "library/tags/1.0"
            2.0.2
                mycode
                library1 -> external of "library/tags/1.1" (inherits property change)
    library1
        trunk   
        tags
            1.0
            1.1
            2.0
            ...

Externals确保您可以选择要包含哪些库更改以及何时需要它。这将有助于减少“意外”。

请注意，虽然svn：externals会减慢你的“svn update”命令，因为每个外部都需要检查。尽管如此，代码正在进行改进。

查看silverstripe公共存储库以了解它们的工作方式。适合他们。

svn propget svn:externals http://svn.silverstripe.com/open/phpinstaller/tags/2.4.2/

希望我能帮忙

Answer 2

没有做任何特别的事情，可能的Subversion目录结构可能如下所示：

repository-root
    site1
        trunk
        tags
            release-20100922
                site1
    site2
        trunk
        tags

    library1
        trunk   
        tags
            release-20100922
                library1

    library2
        trunk   
        tags
            release-20100922
                library2

您和您的开发人员必须确保在版本中的所有组件上创建一致的发布标记。

在site1 release-20100922标记下的某个位置，您可以使用txt文件列出发布中包含的库。

您可以按照概述的方式构建标记。这将是一个手动过程，但可以完成。

Answer 3

我遇到了类似的问题，并使用此存储库结构解决了这个问题：

repository-root
    trunk
        site1
        site2
        library1
        library2
    tags
        site1
            release-20100922
                site1
                site2
                library1
                library2
        site2
            release-20110101
                site1
                site2
                library1
                library2

每次发布时，我都会将整个主干复制到新标签中。标签的第一个子目录显示了我发布的网站。这样我就没有问题来确定库的正确修订版。

是的，对于site1的发布，我也标记了site2。但是，嘿，标记对颠覆来说很便宜。

svn文件夹结构组织

3 个答案: