"Distributed Version Control System" 和 Git 中的 "Distributed" 是什么意思?

what is the meaning of "Distributed" word in "Distributed Version Control System" like Git?

我已经阅读了问题 Distributed Version Control System 以找到答案,但是这个问题是不同的,并且是在将 "Distributed Version Control System" 与其他 "Distributed Systems" 进行比较时出现的。

当我在 "Distributed Database"、"Distributed Cache" 和 "Distributed Computing" 等其他术语中看到单词 "Distributed" 时,我发现数据或计算确实分布在网络上。这里的 "Distributed" 表示 "Divided (equally not always)"。例如,在 Hazelcast a "Distribute Cache system" 中,键实际上是在提供的节点之间划分的。但是我在 "Distributed Version Control System".

中没有发现这种相似性
  1. 分布式是否意味着在 "Distributed Version Control System" 中划分?
  2. 如果是,那么什么是分布式(因为我没有看到代码或提交历史中的划分)?

关于版本控制系统,"distributed"只是"centralized"的反义词。集中式版本控制系统有一个中央或主服务器。它可能有也可能没有额外的服务器,但如果它 确实 有额外的服务器,并且如果这些服务器与指定的中央服务器不一致,那么这些服务器是 错误的: 中央服务器是真相的来源。在分布式版本控制系统中,没有这样的服务器:所有存储库都是对等的,至少从设计的角度来看是这样。当然,任何采用分布式设计的系统都可以像集中式一样使用。通过将 Git 存储库之一指定为更新的主要存储库,可以以这种方式 使用 Git。

When I see word "Distributed" in other terms like "Distributed Database", "Distributed Cache" and "Distributed Computing" then I find that data or computing is really distributed over the network. Here the "Distributed" word means "Divided (equally not always)". For example in Hazelcast a "Distribute Cache system" the keys are really divided among provided nodes. But I do not find this similarity in "Distributed Version Control System".

具有复制功能的分布式数据库不一定划分它们的存储。例如,etcd uses the quorum system to elect a leader; all members of the quorum attempt to keep their copies of the data up to date. Cache behavior in multi-processor systems is often a form of distributed storage as well, though generally considerably more tightly coupled. See, e.g., the Wikipedia entry for cache coherence. Distributed systems with replication can be generally classified via consistency models.

(快速搜索表明 Hazelcast 有备份来处理节点故障,因此他们也必须使用某种一致性模型。如果分布式系统中的某些数据子集仅存储在单个节点上,那么这些数据如果节点失败,则变得不可用。由于失败的概率通常随着节点数量的增加而增加,因此这通常是不可接受的。)