所有项目中的共享组件,是否有比svn:externals更好的替代方案？

Question

我的情况:我有几个组件,有时会对它们进行更改,并在很多不同的项目中共享.每个项目都将这些文件放在名为/ depends的子文件夹中.依赖包含所有常见组件的一堆svn外部.

svn:externals给我带来了很多时间和痛苦.

请记住,我有几个项目(让我们说这个讨论每个使用相同的外部代码10),因此为每个项目保留正常的已提交目录将花费我很多合并时间.

对我的情况有更好的选择吗？

Answer 1

我认为问题的一部分是共享组件的发布周期不一定与项目的发布周期相匹配.

这里描述的共享组件有自己的发布周期.换句话说,每个项目都可以作为一个单独的项目(或者可能是作为一个单独的项目管理它们的集合)进行管理,其中包含自己的发布/版本号.

请注意,该svn:externals定义可以包含特定修订.

这允许使用共享组件的每个项目针对该共享组件(或共享组件的集合)的特定发行版/修订版进行开发,从而为项目提供一组稳定的依赖项.对组件的更改不会破坏项目,因为每个项目都在查看组件的特定修订,而这些修订不一定是HEAD在组件上trunk.

虽然这看起来似乎更多的工作,但我相信从长远来看,这种做法为这种情况提供了更好的变更管理流程.

Answer 2

我同意@Ken.

我非常强烈建议对使用svn:externals在所有没有一个具体的修订.没有修订,就不可能重新创建旧的结账.如果您只在标记时固定外部,则只能重新创建标记的内容.如果你想在trunk中重新创建一些中间版本,你就可以自己动手了.

不分支外部的一个原因是,不清楚应该如何做到这一点.如果项目A的外部指向标签/ 2.0.0并且您正在为项目创建3.4.x分支,那么项目A的外部应该指向什么？应该投射A分支吗？如果是这样,到什么版本？

如果项目具有不同的发布周期,则在分支时通常不可能为外部定义合理的行为.

(svncopy.pl如果您尚未(包含在Subversion源代码分发中)允许您在标记期间固定外部,则可能需要查看该脚本.)

我们发现svn:externals在用于将一组正在积极开发的组件集中在一起时效果很差.外部效果非常适合引入不会移动很多的外部组件,并且您不会遇到分支问题.

Answer 3

我说这个就类似的问题:你应该使用svn:externals的外部从不同仓库的引用.所以svn:externals应该参考位于不同存储库中的组件,模块,第三方工具等.

你应该不使用svn:externals使用的外部指向到同一个存储库来模拟一个"符号链接" -behaviour.

您可以通过修改构建结构或使用checkout-scripts和稀疏结帐功能来解决此类问题.

svn:externals有很多问题,大多数都难以看到,跟踪和修复: 在这里看一个例子

如果使用外部指向其他存储库,则大多数情况下您将不会遇到这些问题.