Technical details on how to store refs #4

创建工单

开启中

由 jcgruenhage 于 2018-06-10 10:35:14 +00:00创建 · 2 评论

jcgruenhage 评论于 2018-06-10 10:35:14 +00:00

管理员

复制链接

I think the main question here is whether to prefer one larger state event over a few smaller ones. We could put all the refs into one large state event, or we could have a state event per ref with the ref being the key.

For the latter approach, we would still need to store the list of all refs somewhere, unless I missed some API to list all state keys for a given event type.

If the power level requirement was on the tuple (event_type, state_key) instead of just event_type, splitting it into multiple events would allow for setting different power level requirements per branch, but a quick read through https://matrix.org/docs/spec/client_server/r0.3.0.html#m-room-power-levels implies that this won't work.

I think the main question here is whether to prefer one larger state event over a few smaller ones. We could put all the refs into one large state event, or we could have a state event per ref with the ref being the key. For the latter approach, we would still need to store the list of all refs somewhere, unless I missed some API to list all state keys for a given event type. If the power level requirement was on the tuple (event_type, state_key) instead of just event_type, splitting it into multiple events would allow for setting different power level requirements per branch, but a quick read through https://matrix.org/docs/spec/client_server/r0.3.0.html#m-room-power-levels implies that this won't work.

jcgruenhage 于 2018-06-10 10:35:26 +00:00 添加了标签

Bikeshedding

jcgruenhage 评论于 2018-06-10 11:35:17 +00:00

作者

管理员

复制链接

So basically either we store an state event of the type git.references and an empty state key, with a content like this:

Large state event:

git.references, empty state key

{
  "tags": [
    {
      "name": "v0.1.0",
      "hash": "sha1ofsomegitobject"
    }
  ],
  "heads": [
    {
      "name": "master",
      "hash": "sha1ofsomegitobject"
    }
  ]
}

Smaller per ref state events

git.references, empty state key

{
  "tags": [
    "v0.1.0"
  ],
  "heads": [
    "master"
  ]
}

git.references.tag, state key v0.1.0

"sha1ofsomegitobject"

git.references.head, state key master

"sha1ofsomegitobject"

Performance

I don't know which of those will perform better or worse, maybe homeserver implementers have a better idea here.

So basically either we store an state event of the type `git.references` and an empty state key, with a content like this: ## Large state event: ### `git.references`, empty state key ```json { "tags": [ { "name": "v0.1.0", "hash": "sha1ofsomegitobject" } ], "heads": [ { "name": "master", "hash": "sha1ofsomegitobject" } ] } ``` ## Smaller per ref state events ### `git.references`, empty state key ```json { "tags": [ "v0.1.0" ], "heads": [ "master" ] } ``` ### `git.references.tag`, state key `v0.1.0` ```json "sha1ofsomegitobject" ``` ### `git.references.head`, state key `master` ```json "sha1ofsomegitobject" ``` ## Performance I don't know which of those will perform better or worse, maybe homeserver implementers have a better idea here.

jcgruenhage 评论于 2018-07-24 17:47:39 +00:00

作者

管理员

复制链接

So I currently prefer the smaller events, most of all because that means that we can merge people pushing to different branches on different servers at the same time. If multiple people push to the same branch at the same time, we'll definitely loose all pushes except one.

So I currently prefer the smaller events, most of all because that means that we can merge people pushing to different branches on different servers at the same time. If multiple people push to the same branch at the same time, we'll definitely loose all pushes except one.

登录 并参与到对话中。

分支/标记未指定

分支列表 标签列表

master

标签

清除选中标签   

Bikeshedding

未选择标签

Bikeshedding

里程碑

取消选中里程碑

无可选项

未选择里程碑

指派成员

取消指派成员

未指派成员

1 名参与者

通知

订阅

到期时间

到期日期无效或超出范围。请使用 'yyyy-mm-dd' 格式。

未设置到期时间。

依赖工单

没有设置依赖项。

参考：jcgruenhage/git-on-matrix#4

没有提供说明。