svn文件夹结构组织

问题描述 投票:1回答:3

在过去的几个月中,我的一个Web应用程序已经从一个项目文件发展到包含多个类库。 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
             ...

现在,因为Site1Site2均引用类库library1library2 ,什么是要去关于重组的文件夹结构,这样的最佳方式

  • 每个站点的标记在创建站点标记时都包含相关类库的冻结副本,并且
  • 每个站点仍可以引用类库,而不必在每个站点的主干中具有单独的副本

我可能只是在想这个错误。 有什么建议吗?

asp.net svn project-management
3个回答
5
投票

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

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
            ...

当您改变主意并决定“嘿,在我们的主干中使用新的2.0 library1 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
            ...

外部组件可确保您可以选择要合并的库更改以及所需的更改时间。 这将有助于减少“意外”。

请注意,尽管svn:externals降低了必须检查的每个外部设备的“ svn update”命令的速度。 正在进行代码改进。

查看silverstripe公共存储库,了解他们的工作方式。 对他们来说效果很好。

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

希望我能帮上忙


1
投票

如果没有做任何特别的事情,可能的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文件,该文件列出了该发行版中包含的库。

您可以按照概述的方式来构造标签。 这将是一个手动过程,但可以完成。


1
投票

我遇到了类似的问题,并通过使用以下存储库结构解决了该问题:

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

每次发布时,我都会将整个行李箱复制到一个新标签。 标签的第一个子目录显示了我发布哪个网站的信息。 这样,我就可以毫无问题地确定库的正确版本。

是的,对于site1的发行版,我也标记了site2。 但是嘿,使用subversion标记很便宜。


推荐问答