Pijul –用Rust编写的数学声音版本控制系统

在“版本控制系统内部的演变”一文中，我们介绍了许多版本控制系统的内部工作原理，包括历史版本和最新版本。但是，我们还没有真正涵盖版本控制的未来。这个领域将如何发展？

尽管Git现在占据主导地位，并且肯定会在未来几年保持强势，但会不会创造出更好的工具？皮约尔可能是一个有力的竞争者。

在本文中，我们将讨论Pijul-一种受到社区关注的Alpha阶段版本控制系统。

Pijul是由Pierre-ÉtienneMeunier和Florent Becker编写的VCS。在2015年至2020年间发布了许多实验原型之后，第一个Alpha版本于2020年11月发布。Pijul通过同时在差异版本和版本上进行操作，结合了第三代VCS的各个方面，例如Git和Darcs。

Pijul用Rust编写，目前处于alpha阶段开发中。为了改善系统的性能和健壮性，最近对Pijul设计的算法和格式进行了全面检查，并且团队正在努力在这些更新之后使它尽可能稳定。

Pijul的架构和设计方法受到Darcs项目的影响，我们在这里详细介绍了该项目。

Pijul（与Darcs共享）的一个显着特征是变更换向，从而可以以任何顺序应用可以独立记录的变更，而不会影响结果。

但是，与仅对更改进行操作的Darcs不同，Pijul将更改应用于代表通用文件的抽象数据结构，从而使其能够维护版本概念以及版本之间的更改概念。这具有许多优点，特别是在性能和​​数学稳健性方面。

可以在https://nest.pijul.com/pijul/pijul中找到Pijul的源代码。 Pijul Nest是用于Pijul存储库的远程托管平台。可以将其视为Pijul的GitHub或BitBucket版本。

我们已经有了Git，这是地球上最流行，功能最强大的VCS。 Git处理了我们可以从可靠的VCS获得的所有功能（实际上，它为这些功能设定了基准），包括：

众多工具可根据所需的工作流程和个人风格方便地管理存储库

在Darcs中，可以更好地将存储库视为“补丁集”（根据需要应用），而不是依赖变更集的线性历史记录。

Darcs模型在诸如重新定级和挑选樱桃之类的操作期间保留补丁程序的身份，而Git有时需要重写历史记录，因为链接标识符取决于应用程序的顺序。保留更改的ID可以认为是一种更自然的方法。

Darcs具有精心设计的界面和命令集，可提供详细的输出，以帮助加快用户的学习速度并阐明用户正在采取的措施。

补丁包可以很容易地通过电子邮件传输，由远程存储库所有者应用。

那么既然我们拥有Git和Darcs，为什么我们需要Pijul？ Pijul的创建是为了解决Git和Darcs中存在的不相关问题。

Pijul使用类似于Darcs的以补丁程序为中心的模型，该模型在重新排序，挑选或重组补丁程序时不需要重写历史记录。所有补丁程序都将永久保留其身份，无论其上下文，顺序，执行的操作或团队工作流程如何。这是一个非常优雅的解决方案，并且可以说是一种更自然的创建此类系统的方法。这与Git相反，在Git中，某些操作（例如重新设置基数和Cherry-Picks）可以更改提交ID（和其他标识符），即使内容本身没有更改。

此外，由于重写了最初的樱桃采摘的提交ID，因此来自Git远程分支的后续樱桃采摘可能导致不自然的冲突。 Pijul完全避免了此问题，因为补丁程序始终保留其身份，无论它们在分支中的位置如何。

那么Darcs呢？在某些情况下，Darcs会遇到性能问题，例如指数合并问题。此问题导致某些合并的难度成倍增加，从而有效地阻止了这些合并的执行。皮约尔解决了这个问题。

正如Pierre Meunier在最近发表的Toward 1.0中所总结的那样：“我们的目标是要找到最小的系统，这是出于数学美学的原因（为什么要存储无用的东西？），而另一个则是出于性能考虑。”

Pijul的主要目的是基于可靠的数学理论，成为高效的VCS，以确保始终保持变更的基本属性。这种一致性增强了软件开发过程中的安全性。使用Pijul，开发人员可以100％确信他们查看的代码是要合并的代码，而Git和Mercurial不一定是这种情况。尽管在这些现有的VCS中似乎很少发生文件改组（并且其中一些被测试捕获），但仍有一些统计研究突出显示了它们的发生，并且对安全性的影响很大。

Pijul的一个特定目标是将冲突建模为正常的协作状态，以便通过正常的更改来解决冲突，即使在任何其他上下文中的相同冲突下也是如此。

Pijul存储库具有一个原始目录，其中包含多个通道。在任何给定时间，通道都包含一组无序更改，也可以将其视为版本，因为独立更改的顺序在Pijul中无关紧要。

“工作副本”只是用户直接可编辑的文件集，而工作副本与原始文件之间的对应关系是由文件跟踪树完成的，这只是工作副本文件与存储在文件中的文件之间的映射。原始的。

而且，更改可以（但不必）相互依赖，并且可以明确地做到这一点（请参阅下面的“样本更改”部分），因为每个更改都是通过其密码哈希和相关性来唯一标识的。是其他更改的显式哈希。最小依赖性由Pijul强制执行，以确保文本编辑有意义。例如，编辑文件或段落的更改取决于引入该文件或段落的更改。这是因为更改一开始从未添加的内容没有任何意义，因此添加内容的补丁必须存在，才能使该补丁具有意义。另外，用户可以指定额外的，特定于语言的依存关系以更准确地对编辑进行建模，例如，引入功能与在另一个文件或同一文件的另一部分中使用它之间的依存关系。这是一个非常强大的功能。

如果需要，这种更改之间的依存关系方案允许Pijul模仿Git和Mercurial使用的提交的严格顺序，从而将Pijul变成一种“ Git，但具有数学上合理的合并”。像这样使用Pijul的缺点是，相对于项目独立功能的更改可能需要在Git分支等不同渠道之间更仔细地划分。 “普通”或“标准” Pijul方法是尝试记录尽可能独立的更改，并将它们保持在同一通道上，因为独立更改可以始终在以后拆分，而无需更改其标识（即哈希） 。通道可用于项目的不同“风格”，并且可以将相同的更改推送到多个通道而无需修改这些更改。

我们想成为Pijul的创建者和首席开发人员Pierre-ÉtienneMeunier的负责人，所以我们问了他一系列有关他的背景和Pijul的创建以及版本控制领域方向的问题。他的回答非常有趣，值得一读（由于篇幅冗长，我们将其分成单独的帖子）。

Pijul的目标之一是最大程度地减少命令数量，以使用户能够尽快全面了解系统。

在这里，创建的有意义的东西是db0，它包含原始格式（二进制格式）和一个示例配置文件，该文件可以TOML格式进行编辑。

pijul add ：将文件添加到存储库的跟踪列表。 pijul remove ：从跟踪列表中删除文件。 pijul mv ：在跟踪列表中移动和/或重命名文件。 pijul ls：显示当前跟踪文件的列表。 pijul记录（或pijul rec）：创建更改并将其应用于原始记录。完成后，.pijul / changes将填充一个更改：

pijul unrecord ：如果没有更改取决于更改哈希，我们还可以使用unrecord命令“撤消”或“取消应用”它。例如，此处更改的哈希为ZNPGE4DJNVY4JAQABNSQ ...，我们可以使用该哈希的任何明确前缀，例如pijul未记录ZNPG甚至pijul未记录Z来撤消它。 pijul reset：将存储库重置为通道状态。不带任何参数的情况下，将使用当前通道，而pijul reset --channel可用于更改当前通道。 pijul fork：创建一个独立通道，其更改与当前通道相同。 pijul channel：列出所有通道。 pijul channel delete ：删除现有通道。 pijul channel重命名 ：重命名现有通道。 pijul push：将更改发送到远程存储库。例如，可以通过pijul push [email protected]：pijul / pijul为Pijul捐款。 pijul pull：从远程存储库获取更改。

以下内容表示将三行的单个文件添加到存储库时获得的更改。一旦出于性能原因将其记录并转换为二进制格式（因为Pijul经常读取更改文件），则其哈希为LXCA3JPGWBSHNWTJLAWL...。

message ='添加文件'timestamp ='2020-11-20T16：46：51.098461926Z'[[authors]] name ='pmeunier'full_name ='Pierre-ÉtienneMeunier'＃更改1。文件添加：“ /” 644 up 1.0中的“文件”，新增0：6+第一行+第二行+第三行

如果我们在第二行和第三行之间添加一行“另一行”，则会得到以下更改：

消息='添加另一行'时间戳='2020-11-20T16：47：58.634094619Z'[[作者]] name ='pmeunier'full_name ='Pierre-ÉtienneMeunier'＃依赖项[2] LXCA3JPGWBSHNWTJLAWLANNSBDQUM4XA3ZLSGKVW6OETSFNY1Q4。在文件中编辑：2 2.7向上2.31，新0:13，向下2.31+另一行

请注意，原始更改作为依赖项存在，由哈希LXCA3JPGWBSHNWTJLAWL ...标识。

总之，Pijul是一个很有前途的项目，正在以优雅的方式实现版本控制。它致力于实现当前工具（如Git和Darcs）所缺少的许多目标。考虑到数学的严格性和性能，它可以解决复杂的问题。软件开发总是为解决现有问题提供新的更好的解决方案的空间。请留意Pijul，因为它可能会直接推动下一代VCS工具的发展。

如果您想了解有关版本控制系统如何在幕后工作的更多信息，请查阅我们的《 Baby Git开发人员指南》，该指南以一种易于访问的方式深入了Git的代码。我们为好奇的开发人员编写了它，以了解版本控制系统如何在代码级别工作。为此，我们记录了Git代码的第一个版本并进行了详细讨论。

希望您喜欢这篇文章！如有任何问题或意见，请随时给我发送电子邮件至[email protected]。