Funziona con la cronologia delle modifiche del contenuto utente: memorizzazione delle differenze rispetto alla duplicazione dei dati

Ciò di cui hai bisogno è un'utilità per differenziare ( Diff ) l'ultimo e il record corrente. Non c'è alcun motivo per reinventare la ruota, quindi cerca su Internet qualcosa che puoi includere nella tua applicazione. Hai solo bisogno di salvare le informazioni che indicano le differenze. Questo può essere annullato per vedere come era il file / record in precedenza.

Poiché la maggior parte degli utenti probabilmente guarderà la versione corrente, la memorizzerei nella sua interezza e forse anche nella precedente. In questo modo, hai solo due copie complete. Dopo la prima modifica, è possibile quindi memorizzare Diff e riavvolgerli appena necessario.

Questo è qualcosa che puoi implementare lentamente nella tua applicazione. Potresti scoprire che c'è poco bisogno di vedere ogni pezzo di storia. I tuoi utenti potrebbero vivere con le ultime 5 modifiche? La dimensione di questi record potrebbe non essere così significativa.

Potresti utilizzare qualche SQLite database (ad esempio pitrdy.sqlite ), con la convenzione di usare contenuto testuale (forse JSON o XML) per cose "ampie" come il tuo "documento". In altre parole, avresti alcune tabelle SQL con alcune colonne TEXT estese contenenti il tuo "testo del contenuto"

My goal is to keep track on edits

Ma prima devi definire ciò che chiami una modifica. Potrebbe essere meno banale di quello che pensi. Potresti voler mantenere solo alcuni dati "validati".

^{(non hai menzionato alcun sistema operativo, suppongo che tu sia su Linux o su qualche sistema operativo POSIX)}

Potresti quindi approfittare di git stesso. Dovresti eseguire la versione sotto git del dump testuale pitrdy.sql del tuo database (ottenuto dal comando sqlite3 pitrdy.sqlite .dump > pitrdy.sql .

Quindi potresti utilizzare git git per fare le conversioni. L'hook pre-commit (da installare, magari come link simbolico, sul file .git/hooks/pre-commit dell'utente client) sarebbe il comando dump

#!/bin/bash
#precommit git hook
# make a backup, just in case
mv -f --backup pitrdy.sql pitrdy.sql~
# dump the sqlite database
squite3 pitrdy.sqlite .dump > pitrdy.sql

L'hook post-merge (da installare, forse come link simbolico, sul .git/hooks/post-merge dell'utente client) sarebbe

#!/bin/bash
#post-merge git hook
# make a backup, just in case
mv -f --backup pitrdy.sqlite pitrdy.sqlite~
sqlite3 pitrdy.sqlite < pitrdy.sql

Uso trucchi simili nel mio basixmo progetto github

Se il tuo "database" sqlite3 pitrdy.sqlite ha una dimensione "ragionevole" (ad esempio qualche dozzina di megabyte al massimo) questo potrebbe essere praticamente sufficiente (vedi questa risposta ).

Forse potresti esaminare i motori Wiki o CMS esistenti ...

Più in generale, potresti mantenere i dati in un formato strutturato testuale (come JSON o XML) e lavorare su questo, ad es. utilizzare un sistema di controllo versione su quei dati testuali. git può gestire qualsiasi tipo di dati (anche binari, come immagini o suoni), ma i dati testuali sono più amichevoli. Il trucco git hook potrebbe essere utile.

dopo la modifica nella domanda

Suggerirei comunque di mantenere i dati testuali in git . Non rinominare il controllo della versione, ma approfittane.

La memorizzazione di tutte le versioni non è un grosso problema, dal momento che lo spazio su disco è davvero economico. Una volta che avrai tonnellate di utenti e gigabyte di dati, potresti permetterti di ridisegnare il tutto. Fino ad allora, mantienilo semplice.

Esamina le Wiki implementazioni (sembrano essere vicine a ciò che desideri), e forse trarre ispirazione da Emacs org-mode