GVFS协议与工作原理

一、环境要求

GVFS的客户端，必须在Windwos 10下编译。而且还必须是最新的版本。Win+R -> winver.exe查看一下，如果版本号不是1703（或以上），就无法正确的运行。

下载免费的Visual Studio 2017社区版，就能够编译。GVFS的Reame里面“Building GVFS”一节，介绍得还是很清楚的，照做即可。

二、如何测试GVFS

目前服务器端对GVFS的支持，只有微软自家的平台才行，不过Visual Studio Online也是免费的，可以自己注册一个。在创建的项目中，记得添加.gitattributes文件，还要包含一行* -text。

编译出来的SetupGVFS.exe，执行一下，就可以在git bash里用了。记住，要以管理员的身份运行git bash！

三、执行过程

在执行完成之后，当前目录下，会出现一个MyFirstProject目录，但是在这个目录下的src文件夹，才是实际的git仓库。

类似于执行以下命令：

# mkdir MyFirstProject# cd MyFirstProject# git clone https://zhuangbiaowei.visualstudio.com/_git/MyFirstProject src

四、执行细节

1. GET /gvfs/config

按照文档的说法，还挺像那么回事的，事实上，微软自己的服务器，返回的内容很简单。

{"AllowedGvfsClientVersions":null}

所以，客户端也表示WARNING: Unable to validate your GVFS  version

新版本的Visual Studio Online加了一个属性：

{"AllowedGvfsClientVersions":null,"CacheServers":[]}

2. GET /info/refs?service=git-upload-pack

这是标准的Git via HTTP，为了取得这个仓库的相关的refs。返回的内容大概是这样的：

001e# service=git-upload-pack000000a551292cea1631238803732c7e89b78243f5f8d6c9 HEAD multi_ack thin-pack side-band side-band-64k no-progress multi_ack_detailed no-done shallow allow-tip-sha1-in-want003f51292cea1631238803732c7e89b78243f5f8d6c9 refs/heads/master0000

其中51292cea1631238803732c7e89b78243f5f8d6c9，就是master分支最新的一次commit id

3. POST /gvfs/objects

按照上一条命令获取的commit id，客户端向服务器提交了一组对象请求。而服务器返回了一个pack文件。这个pack文件包含的objects的规则如下：

objectIds.each do |object_id|
  if  object_id.type == "commit"
    commit_ids = `git rev-list -${CommitDepth} object_id` #取出所需深度的commit_id
    tree_ids = get_all_tree_id(commit_ids)  #只要tree对象，不要blob对象
    object_ids << commit_ids 
    object_ids << tree_ids 
  else
    object_ids << object_id  endend

最后，调用git自身的pack-objects命令，将这些对象打包成一个文件，就可以返回了。

如果我们将请求得到的数据保存为一个文件file-name.pack，可以用以下两条命令，查看这个pack

# git index-pack file-name.pack# git verify-pack -v file-name.pack1a17720ebf1ed29cc384feda3f6b254f71634902 tree   79 86 12
14cc2f21152b7655d869fd8eef97996e54b935f0 commit 232 173 98
......
d2246ca4db84bb71793d1529064f8bd46b283005 tree   63 72 9490
non delta: 86 objects
chain length = 1: 3 objects
objects.pack: ok

4. GET /gvfs/prefetch[?lastPackTimestamp={secondsSinceEpoch}]

在第一次调用时，lastPackTimestamp会等于-1，相当于请求所有历史上曾经在服务器端打包过的文件。之后这个lastPackTimestamp，会变成最近一次的请求时间。

根据我的推断，服务器端应该根据时间戳，将所有这个时间点之后打包的文件，全部计算出来，再打包一次，发送给客户端。

如果将这个获取到的二进制文件打开，我们会看到这样的数据结构：

4750 5245 2001 0100 ddaa 5759 0000 0000# 'GPRE '开头的5个字母# 无符号整数代表版本号，目前为1# 2个字节，代表包数量，目前始终是0100，表示只有一个包# 8个字节，代表一个时间戳，0x5957aadd转换成十进制数是1498917597，是一个UNIX时间戳# Time.at(1498917597) = '2017-07-01 21:59:57 +0800'ffff ffff ffff ff7f ffff ffff ffff ffff# 根据文档，前8个字节代表包的长度，后8个字节代表包的索引，但是目前看来，始终不变。大概因为只有一个包的缘故5041 434b 0000 0002 0000 005b a502 789c # 从这里开始，后续都是原始的pack的内容3334 3030 3331 5108 7275 74f1 75d5 cb4d
6160 f46b 4c6f 0ddf 364d 8c49 2570 c752
998f d521 4adf 00bf a40c 3a93 0b78 9c2b

5. Mounting File Tree

至此，Clone+Fetch commit & tree的操作，全部完成。客户端将会执行mount的操作，利用已经获取到的tree数据，构造出一个FUSE（用户空间文件系统、Filesystem in Userspace，简称FUSE），在过去只有类UNIX操作系统才能支持，现在Windows 10也能够很好的支持了。

有了FUSE，用户看起来就已经获取到了整个git代码仓库，但事实上，客户端只获取到了全部的目录树信息，当用户需要真正需要访问这些文件时，才去服务器端获取。

6. POST /gvfs/sizes

在客户端执行cd src操作之后，用户首次想要查看已经clone下来的git仓库的内容，这时，事实上仓库的内容并不存在。因此，客户端会发起一个sizes请求，在POST的body中提交一堆的对象ID。

[    "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",    "bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb"]

而服务器端，则返回每个对象的大小。这种操作，在git操作仓库时可以通过以下命令获取git cat-file -s obj_id。返回的格式如下：

[
    {        "Id" : "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",        "Size" : 123
    },
    {        "Id" : "bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb",        "Size" : 456
    }
]

7. GET /gvfs/objects/{objectId}

在客户端，如果需要打开某一个具体的文件时，客户端才需要真正获取这个文件的内容，通过一个GET gvfs/objects/obj_id，就可以获取到，服务端的处理也很简单，唯一需要注意的时：HTTP头的内容包括：Content-Type: application/x-git-loose-object

五、深入参考

想要更加深入的理解GVFS，可以参考我最近放出的一个开源项目，是基于ruby语言的gitlab-grack，添加了几个接口，初步能够在任何一种操作系统（不必是Windows）运行一个支持GVFS的git http server，欢迎大家来围观。Grack-with-GVFS

关键的修改，在lib/grack/server.rb与lib/grack/gvfs_helper.rb这两个文件里。