跨存储库/项目的Subversion和共享文件?

时间:2020-03-06 14:44:33  来源:igfitidea点击:

我正在将客户端的SourceSafe资源库(3个项目)迁移到SVN,并且其中两个项目共享源文件。 (这些项目是具有不同名称和发行版本等的单独产品)

SVN是否解决了这一缺点?人们通常如何处理这种情况?

我知道/可以想到的选择

  • 对SVN使用外部或者外部,或者其他任何方式。我听说由于种种原因这不是一个好选择
  • 创建一个包含源的新项目(可能称为共享)。问题在于,我们仍然必须获取该代码(它不是库),然后以某种方式将其导入到项目中。可以证明这是与上述问题相同的问题,并且引入了其他产品/项目的开销。
  • 只需签入两个存储库中的文件并交叉更新即可。这要求开发人员了解共享并记住签入。我想我可以编写一个脚本来检查所有已知的共享文件并在需要时更新它们。
  • 对于共享的两个项目,有一个存储库。这给我留下了必须创建包含两个项目的顶级项目/存储库的问题,这是标记的问题。我真的不想标记顶级伪项目。 (标签,主干和分支的东西并不完全在我想要的位置。)

我可能会选择最后一个选项。

还有其他意见吗?

解决方案

使用触发器来更新文件听起来是个坏主意。他们将以某种方式不同步。实际上,使用共享代码的解决方案是将其提取到一个库中,并在多个解决方案中使用该库。但是,这听起来超出了项目范围,因此最后的解决方案是最佳选择。

以我的经验,有两个独立的项目引用相同的源文件是有问题的,因为我可能会在共享文件中添加或者更改代码以满足一个项目的需求,而这只会破坏另一个版本。

看来,这里的技巧是允许每个项目独立进行,所以无论如何,我们要设置存储库以稳定共享代码,以便仅在需要时才更改。

例如,如果共享代码位于同一个存储库的两个分支/文件夹中,或者被单独检查到两个不同的存储库中,或者共享代码全部位于第三个存储库中,则我们需要执行升级该段代码的步骤成为没有副作用的手动手册,我们可以隔离,调试和修正错误。

我已经将此代码分解到第三个存储库中,然后作为内部发行和升级步骤,将其定期迁移到我的相关项目存储库中。然后,我的各个项目都有一个看起来像"已升级到Shared.App.dll v4.3.345的修订",其中包括针对该版本进行的所有更改。

如果共享代码与两个从属项目是同一存储库的一部分,则在每个项目中都有一个单独的副本,并使用存储库合并来传播更改。

这样做的安全方法是拥有第三个项目,该项目将共享源构建到供其他两个人使用的库中。库项目具有其自己的SVN存储库。

我们甚至可以使用仅标头的共享文件执行此操作,只需将它们保留在lib项目目录中,然后将其添加到包含列表中即可。

即使在soruce控制下,在两个项目中拥有相同的文件,迟早也会给我们带来麻烦!

Have one repository for the two
  projects that share. This leaves me
  with the problem having to create a
  top level project/repository that
  contains the two and it is a problem
  for labeling. I do not really want to
  label the top pseudo project. (the
  tags, trunk and branch things are not
  exactly where I would want them.)

像其他人一样,我一定会做的最后一件事。我们觉得"仅"一个存储库有什么问题?存储库与管理员权限有关。除此之外,我会看到单个回购中包含N个项目。

我不知道我们确切地听说过svn:externals,但是我认为这是我们应该在此处使用的。我们甚至可以指定外部指向共享源的稳定分支或者版本标记,甚至指向使用该源的其他两个项目中的两个不同标记(如果尽快修复共享代码中的某些错误,则可能需要此标记。对于项目A,但是我们没有足够的时间对项目B)进行全面测试。

我们可能要做的最糟糕的事情是选择3(交叉更新同一文件的两个版本)。

当然,请使用一个存储库。稍后可能会有更多的共享代码。

标记到底有什么问题?因此,标签中有一个额外的文件夹,但它不会占用空间。如果我们确实不想要该额外的文件夹,则可以使用以下方法来组织树:

  • prj2
  • 共享
  • 共享

也就是说,当我们要标记prj1时,我们可以创建tag1,然后复制prj1并共享到其中。

我们没有提及正在使用的语言或者构建工具,但是对于Java项目,Maven可能值得研究。功能之一是从本质上扩展了ant,以允许我们引入外部依赖关系。这减轻了我们对必须创建,维护和标记元项目的担忧。它还允许我们从外部项目的HEAD中提取,或者从给定的标记中提取,从而减轻了先前发布者在项目之间共享公用文件而无意间造成损坏的担忧,因为我们可以控制每个项目何时使用共享文件的较新版本。