Keeping all old versions of a tiddler TW5 server

[joearms]

Can I keep all old versions of a tiddler in TW5?

Would this be a good idea? 

(Why? because I made a Wiki a few years ago that did this - and the

overheads were quite small - if you diff and compress the files)

/Joe

[Jeremy Ruston]

Hi Joe

Can I keep all old versions of a tiddler in TW5?

It isn’t supported at the moment. (The TiddlyWeb API does support revisions, but the TW5 client and server just implement minimalist change count tracking to support synchronising).

Would this be a good idea? 

Yes! It’s been on the radar for a while, and we’ve now got many of the required pieces in place.

(Why? because I made a Wiki a few years ago that did this - and the

overheads were quite small - if you diff and compress the files)

We’re in the process of integrating a diff-match-patch library, initially for visualising text diffs, but with an eye to using it for revision support later. I don’t think there’s been much discussion of the implementation approach but I have some thoughts and old notes about it.

Best wishes

Jeremy.

/Joe

--
You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywikide...@googlegroups.com.
To post to this group, send email to tiddly...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywikidev.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/0bce5f6c-250f-45d1-923a-55409e11bd0d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[joearms]

On Friday, 2 March 2018 18:52:22 UTC+1, Jeremy Ruston wrote:

Hi Joe

Can I keep all old versions of a tiddler in TW5?

It isn’t supported at the moment. (The TiddlyWeb API does support revisions, but the TW5 client and server just implement minimalist change count tracking to support synchronising).

Would this be a good idea? 

Yes! It’s been on the radar for a while, and we’ve now got many of the required pieces in place.

(Why? because I made a Wiki a few years ago that did this - and the

overheads were quite small - if you diff and compress the files)

We’re in the process of integrating a diff-match-patch library, initially for visualising text diffs, but with an eye to using it for revision support later. I don’t think there’s been much discussion of the implementation approach but I have some thoughts and old notes about it.

Best wishes

Jeremy.

Interesting - in my earlier wiki (which I wrote many years ago) I did the following

1) save the latest version (as is)

2) save the diff to the latest-1 version

3) concatenate the top version and all the diffs then compress

Now a funny thing happens - consider pure additions to a file

If we start off with K bytes (vsn1) and add N1 bytes

the size of the new file is K + N1 bytes and the size of the 

diff is ~N1 bytes (essentially 'add <string> here')

So the total size is K + 2N1 bytes

After adding N1,N2,N3 bytes the total size is

K + 2*(N1+N2+N3+...) bytes

Now the size of the final file (displayed) is

K + N1 + N2 + N3

So asymptotically N1+N2+N3 ... >> K so we can ignore K

And so the size of the final file = 2 * size of all updates

And if we compress everything we win back a lot of space

The conclusion was we can store all old versions AND it's quite often smaller than

the text of the original page.

This is true for pure additions to a page - removing data is even better

I'll do this when I've got my server going :-)

/Joe