Technical details on how to store refs #4
Rótulos
Sem rótulo
Bikeshedding
Sem etapa
Sem encarregados
1 Participantes
Notificações
Data de vencimento
Sem data de vencimento definida.
Dependências
Não estão definidas dependências.
Referência: jcgruenhage/git-on-matrix#4
Carregando…
Criar uma nova questão referindo esta
Nenhuma descrição fornecida.
Eliminar o ramo "%!s(<nil>)"
Eliminar um ramo é algo permanente. Embora o ramo eliminado possa continuar a existir por um breve período de tempo antes de ser realmente removido, a operação NÃO PODERÁ ser desfeita na maioria dos casos. Quer continuar?
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.
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 keySmaller per ref state events
git.references
, empty state keygit.references.tag
, state keyv0.1.0
git.references.head
, state keymaster
Performance
I don't know which of those will perform better or worse, maybe homeserver implementers have a better idea here.
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.