RepoFS：Git存储库的虚拟文件系统

SoftwareX 9（2019）288原始软件出版物RepoFS：Git存储库的文件系统视图Vitalis Salisa， Diomalus Spinellisb希腊雅典国立技术大学b希腊雅典经济与商业大学ar t i cl e i nf o文章历史记录：接收29四月2018收到修订版2018年12月23日接受2019年保留字：Git虚拟文件系统挖掘软件库Unix shella b st ra ct经验性的软件工程工作通常涉及研究使用流行的Git系统维护的版本控制系统存储库。检查每一个修订一个人想学习是低效的。另一方面，使用Git命令检查过去版本的目录和文件会受到可用性方面的影响。我们将介绍repofs，这是一个将Git存储库公开为虚拟用户级文件系统的工具。提交、分支和标记显示为单独的目录树，允许通过命令行工具和文件浏览器有效地处理它们。我们说明这些点，通过激励的例子，并讨论所提出的方法的优点和缺点。©2019作者由爱思唯尔公司出版这是CC BY许可下的开放获取文章（http://creativecommons.org/licenses/by/4.0/）中找到。代码元数据当前代码版本v0.2.4用于此代码版本的代码/存储库的永久链接https://github.com/ElsevierSoftwareX/SOFTX_2018_49法律代码许可证Apache-2.0许可证使用Git的代码版本控制系统使用的软件代码语言、工具和服务Python 2.7，fuscraft，pygit2编译要求，操作环境依赖性fuscraft，pygit2如果可用，链接到开发人员文档/手册http://github.com/AUEB-BALab/RepoFS/README.md问题支持电子邮件vitsalis@gmail.com1. 介绍经验性的软件工程工作通常涉及研究使用流行的Git系统维护的版本控制系统存储库[1，2]。修订控制系统提供了存储和遍历软件版本的能力，并且几乎被所有专业开发团队使用因此，涉及软件分析、软件演化和软件故障的研究在很大程度上依赖于遍历和检查修订历史的能力。然而，研究人员指出，尽管基于挖掘软件仓库（MSR）的研究依赖于软件工程数据挖掘工具[3]，但只有很少的实用和可重用的工具用于此类任务[4，5]。∗通讯作者。电子邮件地址：vitsalis@gmail.com（V. Salis），dds@aueb.gr（D.Spinellis）。https://doi.org/10.1016/j.softx.2019.03.007在Git系统下，用户可以使用checkout命令在修订版之间切换。然而，在修订版之间切换非常耗时，尤其是在大型存储库中，因为每次都必须更新工作树。此外，命令行工具和文件浏览器一次只能处理一个版本，这使得将分析工具作为不同版本的不同进程运行或并排检查两个不同版本变得很麻烦。签出的另一种选择是GitGit首先，用户必须学习新的命令并记住一个经常不一致的语法. De Rosso等人[6]指出，用户认为Git的界面复杂，违反直觉，难以学习。例如，在某些情况下，文件的 版本 号被 指 定为"revision -- file“，而在其他情况下，它被指定为" revision ：file”。的操作2352-7110/©2019作者。 由Elsevier B.V.出版。这是一篇开放获取的文章，使用CC BY许可证（http://creativecommons.org/licenses/by/4.0/）。可在ScienceDirect上获得目录列表SoftwareX期刊主页：www.elsevier.com/locate/softxV. Salis和D. Spinellis / SoftwareX 9（2019）288289也比在签出树上运行命令效率低得多。然后，Unix shell提供的可用性帮助，如通配符和文件名完成，在Git存储库访问命令中缺失，或者仅提供in a subset子集of cases案件.此外，Git的命令缺乏这样的概念， 当前目录和当前修订的。除非签出一个特定的修订版本来浏览它- 必须在每个Git命令中指定确切的版本号和完整路径。最后，Git命令中缺少目录导航意味着在现有shell目录导航工具之上构建的其他功能，例如在终端窗口上显示当前目录或提供访问过的目录堆栈，在使用Git命令时不可用。在本文中，我们将介绍repofs：一个将Git存储库公开为虚拟用户级文件系统的工具。所有提交、分支、标签和它们所指向的修订内容都显示为单独的目录树，允许它们通过命令行工具和文件浏览器轻松有效地处理因此，repofs不需要执行昂贵的签出操作，它允许通过通用的shell方法而不是定制的ls-tree和show命令同时和按需检查不同目录虚拟文件系统是用户空间和内核之间的中间层模块，允许创建看起来像常规文件系统的东西，而实际上不需要在磁盘上存储任何数据repofs提供了与签出修订版上的shell命令相当的性能，并且在许多情况下比使用Git工具更好的性能。这项工作的贡献是（a）提供了一个开源工具，可以直观和有效地分析Git存储库，（b）说明了该工具所支持的分析方法。2. 工具操作repofs可以通过先安装其依赖项1，然后从Python包索引（PyPI）安装来安装。2它已经在gnu/Linux Debian Stretch发行版下进行了测试repofs作为命令行工具运行，它接受本地Git存储库的路径和挂载目录作为所需参数。rectory，其中存储库的修订历史将被安装为树目录结构。初始化后，挂载的目录将包含以下子目录（见图1）。①的人。commits-by-date目录包含以存储库第一次和最后一次提交的年份范围内的每一年命名的子目录。每个year目录包含每个月的一个目录，而每个月又包含以该月的日期命名的目录。因此，commits/yyyy/mm/dd目录包含了以该日期提交的提交哈希命名的目录。提交引用了仓库的一个给定的状态/版本，我们将其表示为提交哈希目录。每个提交哈希目录包含提交时项目的状态，即与该提交相关联的树结构，其中目录和文件的内容可以以只读方式访问。此外，本发明还提供了一种方法，提交散列目录包含名为.git-parents，包含指向相应提交的父提交的符号链接，以及两个名为.author和.author-email，分别包含提交人的姓名和电子邮件。例如，链接提交日期/2015/11/27/c32. f93/.git-parents/38f. 4b51所需的依赖关系可以在仓库的README页面上找到2 https://pypi.org/网站。包含提交的根目录的内容，哈希值为38f... 4b5，它是具有hash c32.f93，创建于2015-11-27。对于提交散列目录中的每个文件，最后访问和更改时间分别设置为提交的创作和提交时间。请注意，我们使用提交的提交时间来组织committs-by-date目录。commits-by-hash目录包含以存储库中存储的每个提交的提交哈希命名的子目录。提交哈希子目录的行为与按日期提交目录中包含的提交哈希子目录有些工具在遇到目录中有大量文件时会出现问题因此，我们提供了一个选项，可以使用-hash-trees标志创建commits-by-hash当启用-FF.第三级目录将包含以提交的提交哈希命名的子目录，这些提交以三个父目录名称的连接开始。例如，committs-by-hash/af/3d/72目录将包含所有提交的提交哈希目录，其哈希以af 3d 72开始。tags目录包含以存储库中的每个标记命名的符号链接。在Git下，标签指向特定的commits。因此，我们将这种关系表示为文件系统模型中的符号链接，这意味着每个标记都是指向commits-by-hash目录下相应提交目录的符号链接。branches目录包含两个子目录heads和remotes，其中包含存储库的本地和远程分支的名称。根据每个远程存储库的名称进一步组织远程分支，例如起源。每个分支名称都是一个符号链接，指向与该分支相关联的commit hash目录，位于commits-by-hash目录下。包含嵌入斜杠 的 分 支 （ 和 标 签 ） 名 称 会 出 现 在 目 录 布 局 中 ， 例 如remotes/origin/FreeBSD-releng/11.1，并有适当的父目录和内容。repofs不需要硬盘存储，而是使用ram来缓存Git操作的结果。根据我们的测量，可以预期每个提交的内存开销约为0.05kB，每个检索的文件或目录的内存开销为20kB。命令行选项-要卸载虚拟文件系统并终止reepofs进程，应执行shell命令umount3. 执行repofs是用Python实现的。它由两个基本组件组成，一个是提供虚拟文件系统的顶层组件，另一个是与Git接口的底层组件repofs公开的每个根目录都使用路径处理程序提供。路径处理程序抽象了特定于路径的操作，并在严格定义的接口下实现，因此它们可以响应来自顶级组件的查询。顶层组件实现挂载存储库、填充和导航虚拟文件系统以及调用路径处理程序的操作底层组件抽象了仓库上的Git操作。它实现了获取提交、标记、分支、目录树和特定修订的文件内容的方法。路径处理程序可以访问较低级别的组件，这意味着它们可以在Git存储库上执行操作。由于所有组件对于较低级别组件所使用的技术都是不可知的，因此可以很容易地将其替换为更有效的组件。此外，通过定义接口，可以轻松添加新的路径处理程序，从而允许创建新的根级别子目录。290V. Salis和D. Spinellis / SoftwareX 9（2019）288图1.一、存 储 库的 数 据 目 录 结 构 示 例 。repofs 的 实现 基 于 许多 开 源 组件 。 虚 拟 文 件系 统 构 建在fuscraft[7]之上：一个Python模块，为fuse[8]用户空间文件系统提供了一个简单的接口。Git仓库上的操作使用pygit2执行：一组到libgit2[9]共享库的Python绑定。 反过来，libgit2是Git核心方法的无依赖性C实现为了实现在大型存储库上交互使用所需的性能，我们实现了一系列优化。首先，我们为Git操作的结果实现了一个缓存机制此外，为了避免在启动时获得完整提交列表的不可接受的高延迟，我们实现了按日期提交的目录结构，其中每个提交都可以在与其创建日期相关联的目录中访问。这允许我们通过仅获取第一次和最后一次提交的年份来快速挂载文件系统，并使用它们来填充commits-by-date目录。4. 说明性实例shell命令来分析存储库的特定方面。这些例子分为两大类：1. 示例集中在两个大型存储库：Linux内核[10]和Unix历史库[11]，基于实际研究[12]。2. 展示repofs与现有静态分析工具的互操作性的示例。1. Linux 4.9版本包含多少行代码？使用Git，我们执行一个git ls-tree操作，然后对每个结果执行一个git show操作$gitls-tree--name-only-rv4。9|>xargs-I@gitshowwv4. 9： @|wc-l在repofs下，这个数字可以通过列出tags/v4.9下的所有文件名，连接它们，并计算输出的行数来获得。$cdtags/v4. 9$find。 -typef|公司简介|wc-l223483562. 在2006年7月，Linux仓库中创建了多少个提交？使用Git，了解命令行参数 2006年7月，需要。$gitlog--after=“2006-07-0100：00“\>--before=“2006-07-3023：59“|wc-l1480使用repofs，用户可以指定commits-by-date目录3. FreeBSD在其主要版本中的增长是什么？Freebsd的主要发行版使用三位数字命名，最后两位数字为0。使用Git，我们需要遍历所有匹配模式的分支，并执行git ls-tree操作，然后执行gitshow。$forreleasein$（gitbranch--all|>grep“FreeBSD-release/. 2000年。0分。0“）;do>printf>gitls-tree--name-only-r$release|>xargs-I@gitshoww$release： @|（w、c、l）> 做|排序-n使用repofs，行数可以通过切换到Freebsd发行版分支的目录，使用字符串遍历主要分支，并计算每个发行版分支下文件的行数来获得$cdbranches/remotes/origin/FreeBSD-release$forreleasein*. 0的情况。0;do>printf>find$release/-typef|公司简介|（w、c、l）> 做|sort-n3. 0的情况。06377675四、0的情况。0826352 8五、0的情况。01071294 4六、0的情况。01254656 98 .第八条。0的情况。01559358 39 .第九条。0的情况。02126888 7十个0的情况。02507965 311. 0的情况。03078191 14. 2010年1月1日至9日，Linux开发人员每天执行多少次提交和合并？在这样的任务中，需要Unix shell和Git命令的功能：$ g i t日志 - - date=format：% F\>- -before=2010 - 01 - 10--a f te r =2009 - 12 - 31Z23：59：59\>- - pretty = '% cd %p '硕士|>awk' { ncommits [ $1 ] ++;nparents [ $1 ] += NF -1}>结束{ for（a in ncommits）>打印 本发明公开了一种复合材料，ncommits [ a ]，nparents [ a ]-ncommits [ a ] }'|>排序使用repofs，通过使用一个指针迭代指定的日期来获得这些数字。提交的数量是通过计算days目录中的文件数量来找到的，而父节点的数量是通过计算.git-parents元数据目录下的文件数量来找到的。这两个数字之间的差给出了合并提交的数量$cdcommits-by-date2010 / 01 / 0年的$ord？;do>ncommits=$（ls$day|（w、c、l）>nparents =$（find$day-maxdepth3-wholename>'* /。git-parents/*'|（w、c、l）>printf> 做2010/01/012010/01/02下面的段落说明了如何使用简单的Unix7 .第一次会议。0的情况。014432401并计算提交的数量。2010/01/03230$lscomits-by-date/2006/07/*|wc-l2010/01/04841114802010/01/05756V. Salis和D. Spinellis / SoftwareX 9（2019）288291∗∗∗2010/01/06103102010/01/079332010/01/08124182010/01/09705. 在第七次重新搜索版Unix层次结构和FreeBSD 11.0.1发行版中记录了多少个目录？这些数字是通过计算缩进段落的数量来获得的，这些段落的标题以目录层次结构手册页的troff文本标记中的斜杠结尾-通过使用文件名完成，长路径的类型化变得更容易，shell在repofs虚拟文件系统之上透明地实现了该文件名完成。$ g i tgrep- C“^^。IP .//“的时候研究-V7 - - usr /man/man7/usr. 7|> cut -d：- f 3 51git grep命令可以很容易地替换为grep命令。$ grep- C“^^。IP . //“的时候tages/Research-V7/ usr/man/man7/v1.0. 7 51$ grep- C“^^。 我知道。//“的时候branches / remotes / orig in /\> FreeBSD-release/1 1.1.一、0/share/man/man 7/分。72466. JSHint在最新发布的jQuery中产生了多少错误？jshint3是一个静态分析工具，用于评估代码质量。这些数字是通过迭代指定3.0之后版本的标记并对其内容运行jshint获得的。我们只保留错误的数量，即输出的最后一行的第一个字。jshint作用于当前目录树，因此使用每个版本都需要git checkout$fortagin$（gittag|grep“3\. *“）;do>gitcheckout $tag>printf-1|一个wk ’> 做但是，使用repo文件系统可以同时访问不同版本的文件。$光盘标签$fortagin3. *;do>printf-1|一个wk ’> 做3 .第三章。0的情况。0-alpha 13533 .第三章。0的情况。0-alpha 1+compat3743 .第三章。0的情况。0-beta 14273 .第三章。0的情况。0-rc 14253 .第三章。1 .一、05513 .第三章。1 .一、15463 .第三章。二、05493 .第三章。二、15493 .第三章。3 .第三章。05513 .第三章。3 .第三章。15515. 相关工作和性能比较许多工具旨在简化对Git存储库的分析我们将repofs与以下两类工具进行比较：1. 使用Git作为底层存储引擎的文件系统，以及2. 提供包含历史的虚拟文件系统的文件系统。GVFS[13]和GitOD[14]将文件系统虚拟化在Git仓库下，这样Git工具就可以看到看似正常的仓库，而实际上文件并不存在于磁盘上。他们的目标是通过最初只下载必要的文件来减少带宽和磁盘空间的使用。这两个工具都是针对开发人员在大型存储库的特定组件上工作，并且不需要所有组件。相比3http://jshint.com/。对于这些工具，repofs使用Git存储库的本地副本，而不是针对软件开发过程。类似于repofs的工具使用Git存储库的本地副本，并提供对遍历历 史 的 支 持 。 FigFS[15] 提 供 了 包 含 仓 库 历 史 的 commits 、branches和tags子目录。然而，该项目被放弃[16]，并且没有安装说明。GitFS[17]是一个维护良好的项目，支持遍历和查看存储库的历史。然而，它的重点是创建新的提交。尽管GitFS和FigFS都支持使用一个虚拟文件系统，他们不这样做的效率。相比之下，repofs不允许向存储库添加提交，而是专注于有效支持msr任务，这些任务在GitFS和FigFS下的性能可能会很慢。Cosentino等人[18]建议通过将存储库的数据导出到关系数据库来但是，这种方法会创建多个表，这些表很难跟踪，需要SQL知识，并且可能导致为完成简单任务而进行复杂查询。在性能方面，表1比较了使用repofs、GitFS、FigFS、Unixshell和Git命令执行一些代表性操作所花费的时间。准备使用列对应于由于预处理而导致的每个工具的初始化时间。使用find和cat命令是为了获取特定提交下的文件列表，并访问这些文件中每个文件的内容。对应的Git命令分别是git ls-tree和git show。此外，使用ls和git rev-list命令来计算提交的数量。这些操作是在Linux内核存储库上执行的[10]，该存储库目前大小为2.09 GiB，包含超过720，000次提交，跨越13年，最近一次提交包含超过3800万行代码。运行指标的机器，使用gnu/L inux Ubuntu Server发行版，有4个CPU，4 GBRAM和20 GB硬盘存储。时间是五次尝试中最好的，以hh：mm：ss给出，以最大单位精确，并且度量是用冷缓存完成的可以看出，在大多数测试情况下，repofs的性能超过了GitFS和FigFS，在某些情况下有很大的关于FigFS更好的初始化时间，这种差异可以归因于FigFS没有列出仓库的提交，而是依赖于用户知道他们希望访问的提交的提交哈希。请注意，repofs、FigFS和GitFS都避免了检出每个提交的成本6. 讨论和结论Git为协作软件开发提供了一种有效的机制它的存储模型可以很容易地概念化为版本化文件系统。然而，尽管Git通过提供Git存储库的文件系统映射，repofs允许在检查的Git存储库的所有提交、分支和标记上使用已知和常用的Unix shell命令、习惯用法和工具。此外，提供的目录结构可以很容易地被通用gui工具使用，比如文件浏览器和文件差异工具。repofs的未来工作将涉及进一步的时间和内存性能优化。与所有开源软件工具一样，社区采用、反馈以及贡献（希望如此）也将指导工具的发展方向工具的可用性repofs 源 代 码 在 Apache 许 可 证 下 可 用在 GitHub 上 ：https://github.com/AUEB-BALab/RepoFS/。292V. Salis和D. Spinellis / SoftwareX 9（2019）288表1时间性能比较。repofsGitFSFigFS删除提交Git命令准备使用时间00：00：12时间00：01：20<时间00：00：0100：00：15-00：00：5000：00：00列出提交时间00：00：58时间00：21：00时间00：13：02<时间00：00：01<时间00：00：01列出并访问提交的所有文件时间00：03：38时间02：00：00三十三点三十七分时间00：02：08时间00：11：11计数提交时间00：00：26时间02：00：00N/AN/A时间00：00：17致谢所描述的研究是作为crossminer项目的一部分进行的，该项目已根据第2020号赠款协议获得了欧盟地平线2020研究和创新计划的资助。七三二二二三。利益冲突作者对所提议的工具没有利益冲突。引用[1]Bird C，Rigby PC，Barr ET，Hamilton DJ，German DM，Devanbu P.采矿Git的承诺和危险。在：MSR' 0 9 ： 第 六 届 I E E E 国 际 工 作 会 议 上 挖 掘 软件 库 。IEEE; 2009，p.1-10。[2]GermanDM，Adams B，Hassan AE. 持续挖掘分布式版本控制系统：Linux如何使用git的实证研究。恩皮尔软件。 Eng. 2016;21（1）：260-99。[3]Chaturvedi KK，Sing VB，Singh P.采矿软件仓库中的工具，第13届计算科学及其应用国际会议，2013年。pp.89-98.http://dx.doi.org/10.1109/ICCSA.2013.22网站。[4][10]李文辉，李文辉.挖掘软件存档的未来：圆桌会议。IEEE Softw 2009;26（1）：67-70. http://dx.doi.org/10.1109/MS的网站。2009年10月。[5]Spinellis D.工 具 ！ 工 具 ！ 我 们 需 要 工 具 ！ In： Menzies T， Williams L ，Zimmermann T， editors. 软 件工 程 的 数据 科 学 观点 。 Morgan Kaufmann;2016，p. 143比8[6]放大图片作者：Perez De Rosso S. git有什么不好？：概念设计分析。在：2013年ACM国际研讨会上的新思想，新范式，以及对编程软件的反思&。ACM;2013，p. 37比52[7]Verigakis G，Honles T.FUSE的简单ctypes绑定2012年，URLhttps：//github.com/fusepy/fusepy网站。[8]Szeredi M，Rath N，et al. 2001，URL https：//github. com/libfuse/libfuse.[9] libgit2的贡献者Libgit2-git的扩展库。2008年，URLhttps://github.com/libgit2/libgit2。[10]Linux基金会。Linux内核源码树。2005年，URLhttps://github.com/torvalds/linux。[11]Spinellis D. unix历史和发展的知识库。恩皮尔软件。2017;22（3）：1372-404。http://dx.doi.org/10.1007/s10664-016-9445-5网站。[12]Spinellis D ，Avgeriou P. Unix 系统架构 的演变：探 索性案例研 究。IEEETrans Softw Eng 2019.地出现。[13]Microsoft Visual Studio团队服务。Git虚拟文件系统：企业级的git。2017年，URLhttp://gvfs.io。[14]Schroeder J. GitOD ： An on demand distributed file system approach toversion control ， in ： 2012 International Conference on CollaborationTechnologies and Systems （ CTS ） ， 2012 ， pp.613 http://dx.doi.org/10 。1109/CTS.2012.6261115。[15] 简博Git版本控制系统的文件系统接口-最终报告。Tech.代表，2009年，网址http://www.seas.upenn.edu/~cse400/CSE400_2008_2009/websites/grant/final.pdf。[16]简 博 gitfilesystem 的 filesystem 接 口 2008 ， URLhttps ： //github.com/reillyeon/figfs.[17] SRL.版本控制文件系统。2014年，https://github.com/PressLabs/gitfs。[18]Cosentino V ， Izquierdo JLC ， Cabot J. Gitana ： A SQL-based gitrepositoryinspector.在：概念建模国际会议。Springer;2015，p. 329比43