SONAME 库的版本控制最佳实践答案

【问题标题】：Version control best practices for libraries with SONAMESONAME 库的版本控制最佳实践
【发布时间】：2021-09-18 11:16:33
【问题描述】：

我正在为 Linux 创建包和库，其中包括文件名中的包或库版本，soname。当前使用版本控制处理此问题的最佳实践是什么？通常，版本控制将维护映射到用户工作区的版本控制文件的存储库。
我们都知道那首歌和舞蹈：

//repo/myfile.txt#1     //ws/myfile.txt

但是当我使用版本库时，这会变得很麻烦。

//repo/libs/my-library.so.1.0#1    //ws/libs/my-library.so.1.0
//repo/libs/my-library.so.1.1#1    //ws/libs/my-library.so.1.1
. . . 
//repo/libs/my-library.so.3.0#1    //ws/libs/my-library.so.3.0

当我在我的 repo 上执行 get latest 时，我不一定需要每个版本的包，只需要最新版本。此外，版本控制系统的全部意义在于消除开发人员的这种麻烦。但是，实际上用户在分发这些库时确实需要版本化文件名。

有没有办法告诉我的版本控制系统像这样执行地图？

//repo/libs/my-library.so#1     //ws/libs/my-library.so.1.0
//repo/libs/my-library.so#2     //ws/libs/my-library.so.1.1
. . . 
//repo/libs/my-library.so#30    //ws/libs/my-library.so.3.0

在我的具体主观用例中，我使用 Perforce 进行版本控制。但是，我主要对一般的最佳实践感到好奇，而不仅仅是 Perforce 实现这一点的黑客，如果它完全是一种愚蠢的方法。

【问题讨论】：

你的例子中:的意义是什么？你的意思是用# 来表示不同的版本吗？
您是否将共享库存储在您的存储库中？这样做不是最佳做法。
@Samwise，是的，:1 后跟的 repo 路径是文件修订号。我会编辑我的帖子。
@bk2204 是的，我正在存储我的开发团队正在我们的存储库中创建的共享库，以及我们的系统包管理器使用的应用程序二进制文件和 ipk 文件。我们必须维护分布式系统的大型网络，并且我们能够维护旧版本以防技术人员搞砸了，这是一项业务需求。

标签： version-control filenames perforce

【解决方案1】：

由于 soname 描述的是库接口的版本，而不是其实现，因此它大致对应于软件生命周期管理方面的“发布”。在大多数版本控制系统（包括 Perforce）中，这意味着您希望将其表示为某种形式的分支（每个分支可能具有与实现更改相对应的任意数量的修订），而不是将每个单独的修订/提交映射到其自己的 soname .

Perforce 的文件间分支系统使建模变得非常容易——当需要修改 soname 时，你将文件分支到它的新名称，就像你自然会使用 cp 一样，如果你不使用版本控制。（与 git 不同，您不必将整个 repo 全部作为一个单元进行分支；如果需要，每个单独的文件都可以有自己的分支结构，并且变体在客户端文件系统和 repo 中表示。）

如果您当前的项目需要一个特定的 soname 变体，并且您不想在同步时拉下所有其他变体，请将您的客户端视图设置为仅映射您想要的那个。

【讨论】：