相关疑难解决方法(0)

我阅读了颠覆书,我很清楚,subversion不存储单个文件,只存储增量以便最小化磁盘空间.Subversion也对二进制文件做了同样的事情(这曾经是CVS的一个巨大弱点).

但是我不明白确切的机制.当我提交文件时会发生什么？

1. Subversion只存储diff(并且已经有旧版本)
2. Subversion删除以前的版本,保存新文件并创建反向差异,以便在需要时"重新创建"旧版本.
3. 还有一些我没有想过的东西.

第一种情况似乎最合乎逻辑.然而,这提出了另一个问题.如果我在subversion存储库中有一个包含1000个提交的文件,而一个新的开发人员检查出一个干净的副本,那么subversion必须获取原始版本(初始导入)并在返回结果之前对此应用1000个差异.它是否正确？对于保存最新版本的文件,是否存在某种缓存？

基本上我在哪里可以找到有关svn存储库内部的信息？

更新:显然,颠覆的后端在这方面发挥了重要作用.当时或写FSFS使用选项1,而BDB使用选项2.谢谢msemack!

在阅读了很多关于SVN的介绍,入门指南和文档后,我仍然无法弄清楚我的版本控制数据存储在哪里.我的意思是身体.我已经检查了EDIT [1/2 GB]的代码,并且repo只有几MB大.这对我来说仍然是Voodoo.而且,作为一名程序员,我真的不相信魔术师.

编辑: 贡献者声称并非所有代码都存储在回购中,是真的吗？我的意思是,如果我删除我的本地工作副本,我仍然可以取回我的存储库的源代码......如果是这样,我仍然无法理解我的代码如何发生这样的压缩......

编辑2: 当我将代码导入存储库时,我有消息"50MB上传",实际的回购要小得多.必须参与压缩算法.

顺便说一句,阅读一些答案很有趣,看看有多少人确实相信魔术,并且在没有真正使用SVN的情况下知道幕后发生了什么......

考虑这个简单的python代码,它演示了一个非常简单的版本控制设计:

def build_current(history):
    current = {}
    for action, key, value in history:
        assert action in ('set', 'del')
        if action == 'set':
            current[key] = value
        elif action == 'del':
            del current[key]
    return current

history = []
history.append(('set', '1', 'one'))
history.append(('set', '2', 'two'))
history.append(('set', '3', 'three'))
print build_current(history)
history.append(('del', '2', None))
history.append(('set', '1', 'uno'))
history.append(('set', '4', 'four'))
print build_current(history)
for action, key, value in history:
    if key == '2':
        print '(%s, %s, %s)' % (action, key, value)

请注意,通过使用历史列表,您可以在曾经存在的任何状态下重建当前字典.我认为这是一个"前向构建"(缺少一个更好的术语)因为要构建当前字典,必须从头开始并处理整个历史列表.我认为这是最明显和最直接的方法.

正如我所听到的,早期版本控制系统使用了这种"前向构建"过程,但它们并不是最佳的,因为大多数用户更关心构建的最新版本.此外,当用户只关心查看最新版本时,他们不想下载整个历史记录.

那么我的问题是,在版本控制系统中存储历史记录还有哪些其他方法？也许可以使用"向后构建"？这可能允许用户仅下载最近的修订版而不需要整个历史记录.我还看到了一些用于存储历史记录的不同格式,即:变更集,快照和补丁.变更集,快照和补丁之间有什么区别？ …

在阅读了如何和/或为什么在Git中合并比在SVN中更好？ 我还是不明白.假设我有多个版本我正在维护(我需要维护所有版本,所有版本都在生产中):

• V1.0
• V1.1
• V1.2
• V1.3
• V1.4

现在我提交了一个错误修复到v1.0(我需要在所有下一个版本中修复此错误).

现在在git和svn中我必须执行以下逻辑操作

1. X = 1
2. 合并到下一个分支v1.(x)
3. 为v1检查一切正常(测试,构建).(x)
4. x ++ goto(2)直到最后一个分支

使用git(或gerrit)的主要好处是什么？合并到下一个分支,提交,测试的逻辑操作是一样的!那有什么不同呢？(如果它只是次要的合并算法改进,对我来说并不重要.我在Subversion中有一个相当不错的自动合并解决冲突.另外我不介意检查分支v1.1在subversion中进行合并因为我有一些实用程序可以帮助我这样做,所以我没有时间投入其中).