atuin/docs
Ellie Huxtable 29f4a93e30 feat: rework record sync for improved reliability
So, to tell a story

1. We introduced the record sync, intended to be the new algorithm to
   sync history.
2. On top of this, I added the KV store. This was intended as a simple
   test of the record sync, and to see if people wanted that sort of
   functionality
3. History remained syncing via the old means, as while it had issues it
   worked more-or-less OK. And we are aware of its flaws
4. If KV syncing worked ok, history would be moved across

KV syncing ran ok for 6mo or so, so I started to move across history.
For several weeks, I ran a local fork of Atuin + the server that synced
via records instead.

The record store maintained ordering via a linked list, which was a
mistake. It performed well in testing, but was really difficult to debug
and reason about. So when a few small sync issues occured, they took an
extremely long time to debug.

This PR is huge, which I regret. It involves replacing the "parent"
relationship that records once had (pointing to the previous record)
with a simple index (generally referred to as idx). This also means we
had to change the recordindex, which referenced "tails". Tails were the
last item in the chain.

Now that we use an "array" vs linked list, that logic was also replaced.
And is much simpler :D

Same for the queries that act on this data.

----

This isn't final - we still need to add

1. Proper server/client error handling, which has been lacking for a
   while
2. The actual history implementation on top
    This exists in a branch, just without deletions. Won't be much to
    add that, I just don't want to make this any larger than it already
    is

The _only_ caveat here is that we basically lose data synced via the old
record store. This is the KV data from before.

It hasn't been deleted or anything, just no longer hooked up. So it's
totally possible to write a migration script. I just need to do that.
2024-01-01 18:09:23 +00:00
..
docs feat: rework record sync for improved reliability 2024-01-01 18:09:23 +00:00
ru fix: many wins were broken 📝 (#789) 2023-03-19 10:51:05 +00:00
src Tidy up docs (#1120) 2023-07-26 09:47:45 +01:00
static Add release blog post and update docs (#1332) 2023-10-26 09:13:05 +01:00
zh-CN docs: Update sync.md (#1409) 2023-11-22 08:42:52 +00:00
.gitignore Add fancy web docs (#725) 2023-02-25 23:29:59 +00:00
babel.config.js Add fancy web docs (#725) 2023-02-25 23:29:59 +00:00
docusaurus.config.js Move all references to the old repo (#1132) 2023-07-30 23:08:00 +01:00
package-lock.json Bump @babel/traverse from 7.21.2 to 7.23.2 in /docs (#1309) 2023-10-17 15:51:24 -07:00
package.json Add fancy web docs (#725) 2023-02-25 23:29:59 +00:00
README.md Add fancy web docs (#725) 2023-02-25 23:29:59 +00:00
sidebars.js Add fancy web docs (#725) 2023-02-25 23:29:59 +00:00
yarn.lock Bump @babel/traverse from 7.21.2 to 7.23.2 in /docs (#1309) 2023-10-17 15:51:24 -07:00

Website

This website is built using Docusaurus 2, a modern static website generator.

Installation

$ yarn

Local Development

$ yarn start

This command starts a local development server and opens up a browser window. Most changes are reflected live without having to restart the server.

Build

$ yarn build

This command generates static content into the build directory and can be served using any static contents hosting service.

Deployment

Using SSH:

$ USE_SSH=true yarn deploy

Not using SSH:

$ GIT_USER=<Your GitHub username> yarn deploy

If you are using GitHub pages for hosting, this command is a convenient way to build the website and push to the gh-pages branch.