2018-05-18 21:44:14 +02:00
|
|
|
$# This file is part of Vervis.
|
|
|
|
$#
|
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 15:57:42 +02:00
|
|
|
$# Written in 2018, 2019, 2022 by fr33domlover <fr33domlover@riseup.net>.
|
2018-05-18 21:44:14 +02:00
|
|
|
$#
|
|
|
|
$# ♡ 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>
|
2019-08-06 15:23:11 +02:00
|
|
|
$maybe sharer <- msharerWritten
|
2019-06-07 06:26:32 +02:00
|
|
|
^{sharerLinkW sharer}
|
2018-05-18 21:44:14 +02:00
|
|
|
$nothing
|
2019-08-06 15:23:11 +02:00
|
|
|
#{authorName author}
|
|
|
|
$maybe (committer, _) <- patchCommitted patch
|
|
|
|
;
|
|
|
|
$maybe sharer <- msharerCommitted
|
|
|
|
^{sharerLinkW sharer}
|
|
|
|
$nothing
|
|
|
|
#{authorName committer}
|
2018-05-18 21:44:14 +02:00
|
|
|
<tr>
|
|
|
|
<td>At
|
2019-08-06 15:23:11 +02:00
|
|
|
<td>
|
|
|
|
#{showDate written}
|
|
|
|
$maybe (_, committed) <- patchCommitted patch
|
|
|
|
; #{showDate committed}
|
2018-05-18 21:44:14 +02:00
|
|
|
<tr>
|
|
|
|
<td>Title
|
2018-05-25 00:29:08 +02:00
|
|
|
<td>#{patchTitle patch}
|
2018-05-18 21:44:14 +02:00
|
|
|
<tr>
|
|
|
|
<td>Description
|
|
|
|
<td>
|
|
|
|
<p>#{patchDescription patch}
|
|
|
|
|
|
|
|
$if null parents
|
2018-05-21 22:32:34 +02:00
|
|
|
<ul>
|
|
|
|
$forall edit <- patchDiff patch
|
|
|
|
<li>
|
|
|
|
$case edit
|
|
|
|
$of AddTextFile path mode lines
|
|
|
|
<p>Add file #{path} #{mode}
|
2018-05-25 00:42:01 +02:00
|
|
|
<table .lines>
|
2018-05-21 22:32:34 +02:00
|
|
|
$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}
|
2018-05-25 00:42:01 +02:00
|
|
|
<table .lines>
|
2018-05-21 22:32:34 +02:00
|
|
|
$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}
|
2018-05-25 00:42:01 +02:00
|
|
|
<table .lines>
|
2018-05-21 22:32:34 +02:00
|
|
|
$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}
|
2018-05-25 00:42:01 +02:00
|
|
|
<table .lines>
|
2018-05-21 22:32:34 +02:00
|
|
|
$forall (n, t) <- number lines
|
|
|
|
<tr>
|
|
|
|
<td>+
|
|
|
|
<td>#{n}
|
|
|
|
<td>#{t}
|
2018-05-18 21:44:14 +02:00
|
|
|
$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}
|