Die Möglichkeit einen Snapshot eines Projektes zu erzeugen, soll quasi ein Backup sein, zu den man zurückspringen kann. Ein eigener Menüpunkt "Snapshots..." => Auflistung aller Snapshot, neuen Snapshot erstellen von jetzig geladenen Stand (Kopie von project).
Wir müssen uns nur überlegen: Wenn ein Snapshot geladen wird, was passiert mit dem geladenen Stand des Projekts?
Was wir uns sonst noch überlegen müssen, schlag du vor.
Die Möglichkeit einen Snapshot eines Projektes zu erzeugen, soll quasi ein Backup sein, zu den man zurückspringen kann. Ein eigener Menüpunkt "Snapshots..." => Auflistung aller Snapshot, neuen Snapshot erstellen von jetzig geladenen Stand (Kopie von project).
Wir müssen uns nur überlegen: Wenn ein Snapshot geladen wird, was passiert mit dem geladenen Stand des Projekts?
Was wir uns sonst noch überlegen müssen, schlag du vor.
admin
added this to the Development project 2026-09-25 17:35:47 +02:00
admin
moved this to Next in Development on 2026-09-25 17:35:51 +02:00
Entscheidungen vor dem Bau (mit dem User abgestimmt):
Restore: Vor dem Restore wird automatisch ein Snapshot „Before restoring “ vom aktuellen Stand angelegt, dann wird das Projekt überschrieben. Ein Restore lässt sich damit selbst wieder zurücknehmen. Am Server ist der Restore eine neue Revision. Andere offene Tabs bekommen also „changed elsewhere“. Der Editor lädt das Projekt neu, die Undo-Liste ist danach leer, so wie beim Öffnen.
Weitere Vorschläge:
Ein Snapshot ist nur eine Kopie der Projekt-JSON. Bilder, Pixel-Art, Sounds und Fonts sind inhaltsadressiert und werden nie automatisch gelöscht, sie bleiben also erreichbar.
Ablage am Server unter data/snapshots/<projekt-id>/<snapshot-id>.json mit Name, Datum und der Revision, von der er stammt. Zugriff über dieselbe Besitzerprüfung wie beim Projekt. Ein Admin sieht auch die Snapshots fremder Projekte.
Menüpunkt „Snapshots…“: Liste (Name, Datum), „Create snapshot“ mit optionalem Namen (Standard: Datum und Uhrzeit), je Eintrag Restore und Delete.
Erstellen: Zuerst wird der Autosave geleert, dann kopiert der Server den gespeicherten Stand. Im Play wird der Editor-Stand gesichert, nicht die Laufzeitkopie. Bei „changed elsewhere“ wird nichts erstellt.
Wird das Projekt gelöscht, werden seine Snapshots mitgelöscht.
Vorerst nicht dabei: automatische Snapshots, eine Obergrenze pro Projekt, Export als Datei.
Entscheidungen vor dem Bau (mit dem User abgestimmt):
**Restore:** Vor dem Restore wird automatisch ein Snapshot „Before restoring <Name>“ vom aktuellen Stand angelegt, dann wird das Projekt überschrieben. Ein Restore lässt sich damit selbst wieder zurücknehmen. Am Server ist der Restore eine neue Revision. Andere offene Tabs bekommen also „changed elsewhere“. Der Editor lädt das Projekt neu, die Undo-Liste ist danach leer, so wie beim Öffnen.
**Weitere Vorschläge:**
- Ein Snapshot ist nur eine Kopie der Projekt-JSON. Bilder, Pixel-Art, Sounds und Fonts sind inhaltsadressiert und werden nie automatisch gelöscht, sie bleiben also erreichbar.
- Ablage am Server unter `data/snapshots/<projekt-id>/<snapshot-id>.json` mit Name, Datum und der Revision, von der er stammt. Zugriff über dieselbe Besitzerprüfung wie beim Projekt. Ein Admin sieht auch die Snapshots fremder Projekte.
- Menüpunkt „Snapshots…“: Liste (Name, Datum), „Create snapshot“ mit optionalem Namen (Standard: Datum und Uhrzeit), je Eintrag Restore und Delete.
- Erstellen: Zuerst wird der Autosave geleert, dann kopiert der Server den gespeicherten Stand. Im Play wird der Editor-Stand gesichert, nicht die Laufzeitkopie. Bei „changed elsewhere“ wird nichts erstellt.
- Wird das Projekt gelöscht, werden seine Snapshots mitgelöscht.
- Vorerst nicht dabei: automatische Snapshots, eine Obergrenze pro Projekt, Export als Datei.
Umgesetzt in 94749b4, die Doku steht im Wiki (0e42e2f: Concepts, API, Architecture, Development).
Verhalten
Menü → „Snapshots…“ (zwischen „Open project…“ und „Project settings…“): Liste der Snapshots des offenen Projekts mit lokaler Uhrzeit, der neueste oben.
Create snapshot: Name optional, leer = Datum und Uhrzeit. Vorher wird der Autosave geschrieben. Bei ungespeichertem Stand (Play mit offenen Edits, fehlgeschlagener Save, Konflikt) gibt es keinen Snapshot, eine Meldung sagt warum.
Restore: Nach einer Rückfrage wird der jetzige Stand als Before restoring <Name> gesichert, dann wird der Snapshot als neue Revision geschrieben und das Projekt neu geladen (Undo-Liste leer). Ein Restore lässt sich also selbst wieder zurücknehmen.
Delete nach Rückfrage. Wird das Projekt gelöscht, gehen seine Snapshots mit.
Ein Snapshot ist eine Kopie der Projekt-JSON. Bilder, Sounds, Fonts und Pixel-Art sind inhaltsadressiert und werden nie gelöscht.
Umsetzung
Server: api/lib/SnapshotStore.php, Dateien in data/snapshots/<projekt>/ (git-ignoriert), vier Routen unter projects/{id}/snapshots mit derselben Besitzerprüfung wie das Projekt (Admin sieht auch fremde).
Client: SnapshotStore/HttpSnapshotStore in src/core/store/, SnapshotsDialog, Regel als reine Funktion in src/editor/snapshots.ts, Abläufe in ProjectSession. 409 wird zu StaleRevisionError.
Tests
check.sh: 164 Dateien, 2401 Tests, CHECK EXIT 0.
tests/php/snapshots.test.php: 14 Checks grün, läuft im CI-Gate-Job.
5 Unit-Tests in tests/editor/snapshots.test.ts.
Neues e2e-Modul 50 auf einem Wegwerf-Projekt: erstellen, umbenennen, Restore, Restore zurücknehmen, löschen, Projekt löschen → 404 auf die Snapshots. 46b erwartet den Menüpunkt. e2e 46,50: 20 Checks grün. Check-Summe 1385 → 1393 (gerechnet).
Gegenproben: Blocker immer erlaubt → 1 Unit-Test fällt; kein Sortieren → 2 PHP-Checks fallen; Restore ohne Sicherung des alten Stands → 50c fällt, 50d bricht ab.
Nicht per e2e abgedeckt: Sperre während Play und der Konfliktfall (nur Unit-Tests).
Umgesetzt in 94749b4, die Doku steht im Wiki (0e42e2f: *Concepts*, *API*, *Architecture*, *Development*).
## Verhalten
- **Menü → „Snapshots…“** (zwischen „Open project…“ und „Project settings…“): Liste der Snapshots des offenen Projekts mit lokaler Uhrzeit, der neueste oben.
- **Create snapshot:** Name optional, leer = Datum und Uhrzeit. Vorher wird der Autosave geschrieben. Bei ungespeichertem Stand (Play mit offenen Edits, fehlgeschlagener Save, Konflikt) gibt es keinen Snapshot, eine Meldung sagt warum.
- **Restore:** Nach einer Rückfrage wird der jetzige Stand als `Before restoring <Name>` gesichert, dann wird der Snapshot als neue Revision geschrieben und das Projekt neu geladen (Undo-Liste leer). Ein Restore lässt sich also selbst wieder zurücknehmen.
- **Delete** nach Rückfrage. Wird das Projekt gelöscht, gehen seine Snapshots mit.
- Ein Snapshot ist eine Kopie der Projekt-JSON. Bilder, Sounds, Fonts und Pixel-Art sind inhaltsadressiert und werden nie gelöscht.
## Umsetzung
- Server: `api/lib/SnapshotStore.php`, Dateien in `data/snapshots/<projekt>/` (git-ignoriert), vier Routen unter `projects/{id}/snapshots` mit derselben Besitzerprüfung wie das Projekt (Admin sieht auch fremde).
- Client: `SnapshotStore`/`HttpSnapshotStore` in `src/core/store/`, `SnapshotsDialog`, Regel als reine Funktion in `src/editor/snapshots.ts`, Abläufe in `ProjectSession`. 409 wird zu `StaleRevisionError`.
## Tests
- `check.sh`: 164 Dateien, 2401 Tests, `CHECK EXIT 0`.
- `tests/php/snapshots.test.php`: 14 Checks grün, läuft im CI-Gate-Job.
- 5 Unit-Tests in `tests/editor/snapshots.test.ts`.
- Neues e2e-Modul 50 auf einem Wegwerf-Projekt: erstellen, umbenennen, Restore, Restore zurücknehmen, löschen, Projekt löschen → 404 auf die Snapshots. 46b erwartet den Menüpunkt. e2e 46,50: 20 Checks grün. Check-Summe 1385 → 1393 (gerechnet).
- Gegenproben: Blocker immer erlaubt → 1 Unit-Test fällt; kein Sortieren → 2 PHP-Checks fallen; Restore ohne Sicherung des alten Stands → 50c fällt, 50d bricht ab.
- Nicht per e2e abgedeckt: Sperre während Play und der Konfliktfall (nur Unit-Tests).
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Die Möglichkeit einen Snapshot eines Projektes zu erzeugen, soll quasi ein Backup sein, zu den man zurückspringen kann. Ein eigener Menüpunkt "Snapshots..." => Auflistung aller Snapshot, neuen Snapshot erstellen von jetzig geladenen Stand (Kopie von project).
Wir müssen uns nur überlegen: Wenn ein Snapshot geladen wird, was passiert mit dem geladenen Stand des Projekts?
Was wir uns sonst noch überlegen müssen, schlag du vor.
Entscheidungen vor dem Bau (mit dem User abgestimmt):
Restore: Vor dem Restore wird automatisch ein Snapshot „Before restoring “ vom aktuellen Stand angelegt, dann wird das Projekt überschrieben. Ein Restore lässt sich damit selbst wieder zurücknehmen. Am Server ist der Restore eine neue Revision. Andere offene Tabs bekommen also „changed elsewhere“. Der Editor lädt das Projekt neu, die Undo-Liste ist danach leer, so wie beim Öffnen.
Weitere Vorschläge:
data/snapshots/<projekt-id>/<snapshot-id>.jsonmit Name, Datum und der Revision, von der er stammt. Zugriff über dieselbe Besitzerprüfung wie beim Projekt. Ein Admin sieht auch die Snapshots fremder Projekte.Umgesetzt in
94749b4, die Doku steht im Wiki (0e42e2f: Concepts, API, Architecture, Development).Verhalten
Before restoring <Name>gesichert, dann wird der Snapshot als neue Revision geschrieben und das Projekt neu geladen (Undo-Liste leer). Ein Restore lässt sich also selbst wieder zurücknehmen.Umsetzung
api/lib/SnapshotStore.php, Dateien indata/snapshots/<projekt>/(git-ignoriert), vier Routen unterprojects/{id}/snapshotsmit derselben Besitzerprüfung wie das Projekt (Admin sieht auch fremde).SnapshotStore/HttpSnapshotStoreinsrc/core/store/,SnapshotsDialog, Regel als reine Funktion insrc/editor/snapshots.ts, Abläufe inProjectSession. 409 wird zuStaleRevisionError.Tests
check.sh: 164 Dateien, 2401 Tests,CHECK EXIT 0.tests/php/snapshots.test.php: 14 Checks grün, läuft im CI-Gate-Job.tests/editor/snapshots.test.ts.