1
0
Fork 0
mirror of https://code.sup39.dev/repos/Wqawg synced 2024-12-29 02:34:51 +09:00
vervis/templates/repo/patch.hamlet
fr33domlover 2e72684fd5 Switch to new actor layout
This is such a huge patch, it's probably impossible to tell what it does by
looking at the code. One thing is clear: It changes *everything* :P so here's
an overview:

- There are now 5 types of actors, each having its own top-level route
- So projects, repos, etc. are no longer "under" sharers
- Actor routes are now based on their KeyHashid, there are no "idents" anymore,
  i.e. URLs look random and don't contain user or repo names
- No sharers anymore; people and groups are distinct entities not sharing a
  common namespace or anything like that
- Project has been renamed to Deck and it simply means a ticket tracker; repos
  are no longer "under" projects
- In addition to Person, Group, Repo and Deck, there's a new actor type Loom,
  which is a patch tracker; i.e. Repo actors don't manage MRs anymore
- All C2S and S2S is temporarily disabled, because huge changes to the whole
  code are required and I'll do them gradually in the next patches
- Since form-based actions are implemented using C2S, they're disabled as well,
  so Vervis is now essentially read-only
- Some views have been temporarily removed, e.g. repo history and commit view
- A huge set of DB migrations has been added to adapt the DB to these changes;
  I haven't tested them yet on a read DB so there may be errors there; I'll fix
  them in the next patches if I find any (probably going to test on the main
  instance where Vervis itself is hosted...)
- Some modules got tech upgrades, e.g. LocalActor became a higher-kinded type
  and a similar pattern is probably relevant for several other types
- There's an 'Actor' entity in the DB schema now, and all 5 actor types use it
  for common things like inbox and outbox
- Although inbox and outbox are used only by Actor, so essentially could be
  removed, I haven't removed them; that's because I wonder if at some point
  users can have a tree of inboxes much like in email; I don't have an excuse
  for Outbox, but anyway, leaving them as is for now
- Workflows, roles and collaborators are partially removed/unused until I
  figure out a sane federated way to provide these features
- Since repo routes don't contain a "sharer" anymore, SSH URIs are now simpler,
  they already look like user@host/repo regardless of who "controls" that repo
2022-08-15 13:57:42 +00:00

104 lines
3.4 KiB
Text

$# This file is part of Vervis.
$#
$# Written in 2018, 2019, 2022 by fr33domlover <fr33domlover@riseup.net>.
$#
$# ♡ Copying is an act of love. Please copy, reuse and share.
$#
$# The author(s) have dedicated all copyright and related and neighboring
$# rights to this software to the public domain worldwide. This software is
$# distributed without any warranty.
$#
$# You should have received a copy of the CC0 Public Domain Dedication along
$# with this software. If not, see
$# <http://creativecommons.org/publicdomain/zero/1.0/>.
<table>
<tr>
<td>By
<td>
$maybe sharer <- msharerWritten
^{sharerLinkW sharer}
$nothing
#{authorName author}
$maybe (committer, _) <- patchCommitted patch
;
$maybe sharer <- msharerCommitted
^{sharerLinkW sharer}
$nothing
#{authorName committer}
<tr>
<td>At
<td>
#{showDate written}
$maybe (_, committed) <- patchCommitted patch
; #{showDate committed}
<tr>
<td>Title
<td>#{patchTitle patch}
<tr>
<td>Description
<td>
<p>#{patchDescription patch}
$if null parents
<ul>
$forall edit <- patchDiff patch
<li>
$case edit
$of AddTextFile path mode lines
<p>Add file #{path} #{mode}
<table .lines>
$forall (n, t) <- number lines
<tr>
<td>+
<td>#{n}
<td>#{t}
$of AddBinaryFile path mode size
<p>Add binary file #{path} #{mode} #{size}
$of RemoveTextFile path mode lines
<p>Remove file #{path} #{mode}
<table .lines>
$forall (n, t) <- number lines
<tr>
<td>-
<td>#{n}
<td>#{t}
$of RemoveBinaryFile path mode size
<p>Remove binary file #{path} #{mode} #{size}
$of MoveFile oldPath oldMode newPath newMode
<p>Move file #{oldPath} #{oldMode} → #{newPath} #{newMode}
$of ChmodFile path old new
<p>Change file mode #{path} #{old} → #{new}
$of EditTextFile path orig hunks oldMode newMode
<p>Edit file #{path} #{oldMode} → #{newMode}
^{inlineDiffW orig hunks}
$of EditBinaryFile path oldSize oldMode newSize newMode
<p>
Edit binary file #{path} #{oldSize} #{oldMode} →
#{newSize} #{newMode}
$of TextToBinary path lines oldMode newSize newMode
<p>Edit file #{path} #{oldMode} → #{newSize} #{newMode}
<table .lines>
$forall (n, t) <- number lines
<tr>
<td>-
<td>#{n}
<td>#{t}
$of BinaryToText path oldSize oldMode lines newMode
<p>Edit file #{path} #{oldMode} #{oldSize} → #{newMode}
<table .lines>
$forall (n, t) <- number lines
<tr>
<td>+
<td>#{n}
<td>#{t}
$else
<p>
This commit has multiple parents, and to be honest, I'm unsure how exactly
to decide against which one to run the diff. Do I just pick the first
parent? Or otherwise somehow detect which one is the right one? Advice is
very welcome. For now, to help me find and observe such cases, I'm just
listing here the parents of the commit:
<ol>
$forall parent <- parents
<li>#{parent}