代码之家 › 专栏 › 技术社区 › aleemb

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

branch repository svn

aleemb · 技术社区 · 15 年前

我在一个存储库中有多个网站项目,每个项目都有一个WordPress的副本。更新WordPress意味着更新所有项目文件夹并保留冗余副本。这对于同步整个文件夹的rsync脚本很有用。它也给了我完整的工作现场的本地副本。

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

在每个网站文件夹中创建指向WordPress位的符号链接。这会在颠覆和阿帕奇中继续吗?有什么缺点吗?
拥有一个WordPress文件夹,并将其分支到其他网站的主干中。我读到分支很便宜,维护了一个副本,但我不确定是否应该跨主干进行分支。我个人认为这是最好的方法。有什么理由避免这样做吗?
最后,我可以保留当前的结构,并使用脚本在所有网站文件夹中进行复制。

最好的方法是什么?还有其他的解决方案吗?

8 回复 | 直到 15 年前

Epcylon 15 年前

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

Externals Definitions in the SVN book

leander 15 年前

如果您已经将所有站点托管在一个存储库中,那么可以使用svn:externals以各种方式将同一存储库的不同部分拉到一起。

例如,使用类似

repo/site1
repo/site2
repo/commonPieces

您可以在Site1和Site2目录上引入“svn:externals”属性,该属性表示“要回购的CommonPieces URL/CommonPieces”。

显然,您需要避免这里的任何递归循环。但是这样做的好处是,所有内容都在同一个存储库中,并且可以共享历史——您可以使用“svn copy”将越来越常见的内容从Site1或Site2拉到Commonpies中。

比较我们当前正在使用的解决方案--从我们的分离将存储库投影到单个 也分开 “核心库”存储库丢失了开发历史。因为我们通常为一个项目开发特性,然后决定重新使用它们,所以历史的丢失会发生很多…

编辑:值得记住的是,尽管Site1上的“svn update”将自动更新具有此“svn:externals”属性的CommonPieces,但Site1上的“svn commit”将不会显示Site1/CommonPieces中已更改的内容。您必须进行两次单独的提交,一次来自Site1,另一次来自Site1/Commonpies。

Christian C. Salvadó 15 年前

你可以添加一个 svn:external 指向的定义 WordPress repository 或者用你使用的插件和定制创建你自己的“定制WordPress存储库”。

Theo.T 15 年前

我经常会在不同的项目中重复使用相同的类库,在我的例子中,我更喜欢为每个项目使用单独的冻结副本。唯一的原因是我不想破坏我已经有一段时间没做过的项目,以防其中一个图书馆超过它。但是,如果每个项目都是某个主要项目的一部分,那么您将不断地进行不同的工作。

Jonathan Beerhalter 15 年前

也许我只是用了一种错误的方法来进行Subversion,但是我们的文件夹结构如下所示

躯干核心 -消息传递 -超强的应用1 -超强的应用2 -超强的应用3

所以我们所有的应用程序都共享相同的核心和消息传递组件。唯一的缺点是,当人们进行分支时,他们会得到所有的应用程序,但这比任何事情都更烦人。

Dana the Sane 15 年前

一个更好的方法是将WordPress拉到存储库的一个单独的分支中。然后,为每个网站引入一个配置文件来存储WordPress的路径。可以将此位置附加到php include路径。这是一个图表:

Svn repo-v
         |-Websites--v
         |           |---One
         |           |---Two
         |-Wordpress-v
                     |---branch one
                     |---branch two

这有两个优点:

你可以同时使用几个版本的WordPress进行测试,也可以不进行测试。您可以在所有网站之间共享这些
你不必担心WordPress在哪里结账。在一个项目中包含一个库通常是混乱的,但是这种类型的设置使得把事情放在某个公共位置更加容易。
您不必维护库的多个版本,更新更容易。

Evert 15 年前

传统上,一切都应该在SVN上分离。听起来你是在用SVN从不同的区域获取代码并将它们缝合在一起。

所以您使用SVN作为构建工具。最好是:

把你的插件分开
不要将WordPress本身存储在SVN中,除非使用供应商分支
当您需要使用特定组件获取特定的应用程序时,请使用构建脚本。

gahooa 15 年前

最好的方法是什么?还有其他的解决方案吗?

不要离题,但我建议你仔细看看 git. 我们日复一日地用子模块做这种事情,这是一种微风。

FYI-大约2年前由于这些问题从SVN迁移过来。