相关疑难解决方法(0)

我会在版本控制下放置大量数据,即目录结构(深度<= 5),数百个文件,大小约为500Mb).

我需要的是一个系统,可以帮助我: - 检测文件是否已被更改 - 检测文件是否被添加/删除 - 克隆整个存储库在另一个位置 - 存储"检查点"并在以后恢复

我不需要sha1进行变化检测,更快的速度是可以接受的.

git值得吗？还有更好的选择吗？

NB 我认为答案可能是以设计为中心的,因此基本上与实现无关,但如果有一些特别适合使用这些技术的解决方案,我将使用Java + Hibernate和Postgres.

我有一个包含特定字段的表格,它会包含大字符串,让我们说博客帖子平均为+10000个字符.

在我的应用程序中,您可以根据需要多次编辑博客帖子,并且在更新后将立即显示最新版本.但是,应用程序需要保留这些编辑的完整版本历史记录,以便查看它们.

一个明显的策略是保留一个单独的表,例如blog_post_history,博客帖子行在创建时重复插入,每次后续更新到主"实时" blog_post表,并带有递增的版本号,因此如果需要,这些版本都可用未来.我正在考虑使用像Hibernate Envers这样的东西进行设置.

然而,存储(和 - 可能更重要的是 - 传输),10000字符文本块的多个版本似乎非常低效,其中每个文本块之间的唯一区别可能是修复拼写错误,添加几个单词等.由于其性质对博客文章进行编辑时,可能会有许多像这样的小增量变化,而不是更少,更大的变化.

有没有更好的办法？

我正在考虑在编辑时仅存储当前版本和先前版本之间的增量,然后在请求时以编程方式从这些增量重建版本历史记录,可能在客户端上,因此通过网络发送的数据是最小化.

我很可能将最新版本存储为全文,因为我想优化请求最频繁,然后存储从当前版本向后的增量链,以便在请求它们时重建历史版本.

我知道git lfs用我的存储库中的指针文件替换了lfs跟踪的文件.

我不明白的是我从那件事中获得的东西.

是不是我永远不必下载与我从未结帐的提交相关联的二进制文件？

还是有其他优势？

所以我已经开始使用git了一段时间,并逐渐理解它是如何工作的.我理解的一个要点是 - 每次进行新提交时都会创建一个快照.当然,快照只包含已更改的文件和指向未更改文件的指针.

根据ProGit§1.3入门 - Git Basics

每次你在Git中提交或保存项目的状态时,它基本上都会记录当时所有文件的外观,并存储对该快照的引用.为了提高效率,如果文件没有改变,Git不会再次存储文件 - 只是指向它已存储的先前相同文件的链接.

但是,假设我有一个很大的文件,例如2GB的文本文件.我将该文件更改10次,因此每天进行10次提交,这是否意味着 - 我现在在我的计算机上有10个2GB文件？这似乎对我来说效率很低所以我相信情况可能并非如此.

有人可以澄清这种情况会发生什么吗？

• Git中的某些操作（例如checkout）似乎假定提交是工作树的快照或状态。
• Git中的其他操作（例如rebase）似乎假定提交是更改：可以应用于工作树的一种运算符。

那么，什么是Git提交呢？

当我执行时git push，它显示以下输出

Counting objects: 214, done.                               
Delta compression using up to 4 threads.                   
Compressing objects: 100% (213/213), done.                 
Writing objects:  26% (57/214), 27.44 MiB | 60.00 KiB/s 

由此可见，Git 使用了 delta 压缩方法。增量压缩如何工作？它也可以用于其他应用程序吗？如果是，请推荐此类应用程序。

我有兴趣在 git 中存储一个固定大小的 EEPROM HEX 文件。这些文件永远不会改变大小，但它们会经常改变内容。

如果我将一个 EEPROM 文件添加到 git 并提交它，然后我更改文件中的几个字节，git 会在数十或数百次提交中有效地存储此更改吗？

在我对这个问题的研究中，我对这个主题进行了一些彻底的讨论，但其中大多数似乎处理的是 PDF 和 MP3 之类的文件，没有人希望这些文件保持不变或在差异中具有可比性。我想知道 EEPROM HEX 文件是否会因为文件大小保持不变而被区别对待？

编辑（再次）

一些初步观察......（感谢 Krumelur 的“尝试一下”的鼓励！）

我正在测试的文件是一个 7MB 的 Intel HEX 文件。根据 git 的输出，它似乎将此文件视为文本文件：

$ git commit -m "Changed a single byte."
[master bc2958b] Changed a single byte.
1 file changed, 1 insertion(+), 1 deletion(-)

diff 输出也匹配：

$ git show bc2958b
commit bc2958b[...]
Author: ThoughtProcess <blah@blah.com>
Date:   Wed Jul 31 11:53:41 2013 -0500

    Changed a single byte.

diff --git a/test.hex …

我在我的笔记本电脑上的git repo中有我的代码库,我在外部硬盘上设置了一个裸git repo用于我的备份.我成功推送了我的第一次提交,但注意到我的外部硬盘驱动器上的备份存储库没有显示文件.

如果我的笔记本电脑崩溃,我将如何恢复完整的代码库？在我的外置硬盘上设置为裸仓库不正确吗？

谢谢Dusty

我一直在阅读 git 书。在这本书中，我了解到 git 是通过拍摄您使用的文件的快照而不是像其他 VCS 那样的增量来运行的。这有一些很好的好处。

然而，这让我想知道：随着时间的推移，包含这些快照的 .git/ 文件夹不应该变得太大吗？有些存储库具有 10,000 多个提交或更多，包含数百个文件。为什么 git 不会变大？

每个 Git 提交对象都指向一个树对象。每个提交树对象是否都存储其所有条目，还是仅添加新条目并且仅包含来自提交父级的增量？

例如，Linux 源代码有 1M 提交和数千个对象（master 有 70,000 个）。如果每个提交对象都包含所有对象的条目，从长远来看将占用巨大的空间。即使提交/推送一行更改，也会进行大量处理和传输。

我理解 Git 的理念是存储快照而不是文件的增量，但在这种情况下，只存储更改的文件。

在下面的示例中，70951b429e0e1191a8c1d9e34248cd76453ef544 包含（或显示为 containsig）所有 5 个文件，即使只添加了一个文件。

[test]$ls
a.txt  b.txt  c.txt  d.txt
[test]$echo r5 > e.txt
[test]$git add -A && git commit -m "r5"
[master 51f6941] r5
[test]$git cat-file -p 51f6941
tree 70951b429e0e1191a8c1d9e34248cd76453ef544
[test]$git cat-file -p 70951b429e0e1191a8c1d9e34248cd76453ef544
100644 blob 9a6c8d12dea8859b821b2ba705f7efd6cc914aa5    a.txt
100644 blob 9a6c8d12dea8859b821b2ba705f7efd6cc914aa5    b.txt
100644 blob b6693b64f528de38cde5533acd781fde743bc3df    c.txt
100644 blob 91174caefafdc81d34e302874c86c6e4d5212075    d.txt
100644 blob 29f4cfc46ba3a0bde55bce8f44ac3590e2108da4    e.txt