当前位置:  开发笔记 > 运维 > 正文

SVN:跨项目共享公共代码的最佳方式

如何解决《SVN:跨项目共享公共代码的最佳方式》经验,为你挑选了2个好方法。

我在一个存储库中有多个网站项目,每个存储库都有一个WordPress副本.更新WordPress意味着更新所有项目文件夹并保留冗余副本.这对于同步整个文件夹的rsync脚本非常有用.它还为我提供了完整的网站本地副本.

我可以通过多种方式来改进这一点,并希望得到一些反馈.我在Windows上,最近迁移到Subversion.

    创建每个网站文件夹中WordPress位的符号链接.这将在Subversion和Apache中占据上风.有什么缺点吗?

    有一个WordPress文件夹并将其分支到其他网站中继.我读到分支很便宜并且维护了一个副本,但我不确定是否应该跨越中继进行分支.就个人而言,我认为这是最好的方法.有没有理由避免这种情况?

    最后,我可以保留当前结构并使用脚本在所有网站文件夹中进行复制.

什么是最好的方法,有没有替代解决方案?



1> Epcylon..:

一种选择是将WordPress位分离到一个单独的存储库中(因为它实际上不是你的项目的一部分,它只是用来构建它们的东西),然后使用svn:externals将它们提取到项目中的正确位置.

SVN书中的外部定义



2> leander..:

如果您已经将所有站点集中在一个存储库中,则可以使用svn:externals以各种方式将同一存储库的不同部分集中在一起.

例如,有一个像

repo/site1
repo/site2
repo/commonPieces

你可以在site1和site2目录上引入一个"svn:externals"属性,上面写着"commonPieces url-to-repo/commonPieces".

你明白要避免任何递归循环.但这样做的好处是,所有内容都在同一个存储库中并且可以共享历史记录 - 您可以使用"svn copy"将从site1或site2变得更常见的内容拉到commonPieces中.

比较我正在工作的当前解决方案 - 将我们单独的项目存储库中的东西迁移到单独的 "coreLibraries"存储库中会丢失开发历史记录.由于我们通常为一个项目开发功能,然后决定重新使用它们,因此这种历史的丢失发生了很多......


编辑:值得记住的是,虽然site1上的"svn update"将自动更新具有此"svn:externals"属性的commonPieces,但site1上的"svn commit"将不会显示site1/commonPieces中已更改的内容.您必须进行两次单独的提交,一次来自site1,另一次来自site1/commonPieces.

推荐阅读
贾志军
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有