在过去的几个月中,我的一个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
...
现在,因为Site1
和Site2
均引用类库library1
和library2
,什么是要去关于重组的文件夹结构,这样的最佳方式
我可能只是在想这个错误。 有什么建议吗?
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/
希望我能帮上忙
如果没有做任何特别的事情,可能的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文件,该文件列出了该发行版中包含的库。
您可以按照概述的方式来构造标签。 这将是一个手动过程,但可以完成。
我遇到了类似的问题,并通过使用以下存储库结构解决了该问题:
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标记很便宜。