Mercurial 变更集的列表大小?
寻求量化每个变更集中发生了多少变更。有什么快速方法可以列出两个修订版之间的 kb 差异吗?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
寻求量化每个变更集中发生了多少变更。有什么快速方法可以列出两个修订版之间的 kb 差异吗?
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
接受
或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论(4)
昨天我和@shambulator有同样的想法!因此,我添加了打印 增量大小(以字节为单位) 的功能我的 --diffstat 输出href="https://github.com/techtonik/python-patch/blob/master/patch.py" rel="nofollow noreferrer">有点长且干净的 patch.py 实用程序。
UPD:感谢 @Gili 和 @mforbes,现在有一张 Mercurial 的门票
https://bz.mercurial-scm.org/show_bug.cgi?id= 4245
I had the same thought as @shambulator yesterday! So I've added ability to print delta size in bytes as a part of
--diffstat
output from my somewhat long and clean patch.py utility.UPD: Thanks to @Gili and @mforbes there is now a ticket for Mercurial
https://bz.mercurial-scm.org/show_bug.cgi?id=4245
也许可以使用
hg bundle
来检查尺寸? (我还没有检查这与存储库总大小的一致性。)它是如何工作的
这使用
wc -c
生成修订版之间的更改的捆绑包后REV = $1
(bash 函数的第一个参数)和其父级"p1(REV)+p2( REV)"
(如果是合并,则可能有两个。)通过使用/dev/stdout
作为文件,结果将发送到标准输出,并可通过管道传输到 <代码>厕所-c 不在磁盘上创建文件。Perhaps one can use
hg bundle
to check the size? (I have not checked how consistent this is in terms of the total repository size.)How it works
This computes the size (in bytes) using
wc -c
after generating a bundle for the changes between revisionREV = $1
(the first argument to the bash function) and its parents"p1(REV)+p2(REV)"
(there may be two if it is a merge.) By using/dev/stdout
as a file, the result is sent to standard out where it can be piped towc -c
without creating a file on disk.hg log --stat
是您要执行的命令。看这个例子:hg log --stat
is the command you're after. See this example:昨天我也有同样的想法!我编写了一个快速而肮脏的Python脚本,用于确定给定标准输入上的统一差异或作为文件上的总文件大小变化命令行。要对变更集执行此操作,您可以:
快速而肮脏,因为它可能不考虑特定于平台的行结尾,并且它不会特别巧妙地解析差异。但对于我的目的来说已经足够接近了。
I had the same thought only yesterday! I wrote a quick and dirty Python script for determining total file size change given a unified diff on stdin or as files on the command line. To do it for a changeset, you could just:
Quick and dirty in the sense that it probably doesn't account for platform-specific line endings, and it doesn't parse diffs particularly cleverly. But it's close enough for my purposes.