Git和Mercurial - 有人可以解释这个测试结果

ron*_*ana 5 git mercurial

我正在对GIT和Mercurial的速度进行比较.
我选择了一个9072文件的大项目(主要是php文件和几个图像),大小为95.1 MB.

这是一个虚假的项目,也许可以让某人知道如何解释我得到的结果 - 这是一个wordpress下载,未更改,并在两个文件夹中复制了12次 - 一个用于GIT,另一个用于Mercurial存储库.

然后我创建一个GIT存储库并提交(使用TortoiseGIT),完成后,我在使用TortoiseHG的Mercurial的另一个文件夹上做了同样的事情.

Git结果
时间:32分30秒提交一切
存储库大小:6.38MB,只有847个文件.

Mercurial结果:
时间:1分25秒 - 是的,它只有1分钟.
存储库大小:58.8MB,包含9087个文件.

我不是在争论最好或者其他什么,我只是想了解差异以及SCM如何创建存储库.

看起来HG做了一些文件的副本,带有某种压缩.
但我不明白Git做了什么.
有人能解释一下结果吗?

PS.:我知道已经有一些关于GIT和Mercurial的问题,我只想弄清楚这个测试的结果 - 即使它是一个有效的测试.当我开始时我只是检查速度,但我最终在我的头顶上留下了一些问号......

Jos*_*Lee 18

检查您的工具; hg和git(命令行)都会在大约一秒钟内导入这些树.考虑工具的命令行版本而不是GUI包装器.

你遇到了git excels和hg效率低下的情况.Mercurial使用单独的文件作为每个文件的revlog,而git喜欢使事情更加统一.特别是,复制相同的目录十二次在git中几乎没有额外的空间.但这种情况多久发生一次?我希望不是很好.如果您经常导入数千个文件和图像,而不仅仅是初始提交,则DVCS可能不适合您.像rsync或集中式VCS这样的东西会更好 - DVCS通常针对一个项目进行调整,该项目包含文本文件并接收补丁并随着时间的推移进行合并.其他类型的工具做出不同的权衡.

导入大型目录树并仔细检查出现的文件真的没什么意义; 如果您愿意,可以阅读文档.这里的主要教训是git保留了整个目录结构的快照,这使得它可以有效地打包(wordpress的包是2.7MB,不比tarball大),但计算差异可能更昂贵.Mercurial维护了更多的每个文件信息,如日志和差异,这意味着只访问一个文件的日志比git快得多,但许多相同的文件和目录可能会有更高的空间成本.

我也可以创造一个病态案例.这是git赢得的一个:

for dir in {1..100}; do
  mkdir $dir
  for file in {1..100}; do
    touch $dir/$file
  done
done
hg add {1..100}; hg commit -m tweedledee
git add {1..100}; git commit -m tweedledum
Run Code Online (Sandbox Code Playgroud)

是的,这是100个相同目录中的10,000个空文件.Git在十分之一秒内导入整个东西,并且提交本身不到一千字节.Mercurial为每个文件创建一个日志文件,大约需要四秒钟来提交整个文件,最终得到10140个.hg的新文件,总计40MB.

这是mercurial获胜的地方:

mkdir -p a/b/c/d/e
for i in {1..1000}; do
  echo hello >> a/b/c/d/e/file
  hg add a; hg commit -m "Commit $i"
  git add a; git commit -m "Commit $i"
done
Run Code Online (Sandbox Code Playgroud)

这是一千个提交,每个提交在深层嵌套文件中引入一个微小的变化.git中的每个提交都引入了八个新对象,这些对象单独放气但存储为单独的文件.最终,git决定重新打包,这需要时间.打开包装,整件大约32MB,包装为620K.另一方面,Mercurial每次只需在几个日志文件中添加几个注释,最后的.hg为396K.

这一切有什么意义?关键是这个线程中讨论的所有案例都不现实.在日常使用中,使用现实的存储库,这两种工具都很棒.只学一个.

本身不完全告诉你从开始的手册,到底是怎么提交的构造,但在Pro的Git Git的内幕,内幕在水银的wiki,并从2010年PYCON水银内幕应该让你开始.

  • 还有,在Hg中有一个功能,称为轻量级副本,它消除了复制文件时的大部分开销. (3认同)