Remove outdated configuration items.

README.md

@@ -114,7 +114,6 @@ If you have deleted or renamed files, please wait until ⏳ icon disappeared.
 -   There are no 'exclude_folders' like configurations.
 -   While synchronizing, files are compared by their modification time and the older ones will be overwritten by the newer ones. Then plugin checks for conflicts and if a merge is needed, a dialog will open.
 -   Rarely, a file in the database could be corrupted. The plugin will not write to local storage when a file looks corrupted. If a local version of the file is on your device, the corruption could be fixed by editing the local file and synchronizing it. But if the file does not exist on any of your devices, then it can not be rescued. In this case you can delete these items from the settings dialog.
--   If your database looks corrupted, try "Drop History". Usually, It is the easiest way.
 -   To stop the boot up sequence (eg. for fixing problems on databases), you can put a `redflag.md` file at the root of your vault.
 -   Q: Database is growing, how can I shrink it down?
     A: each of the docs is saved with their past 100 revisions for detecting and resolving conflicts. Picturing that one device has been offline for a while, and comes online again. The device has to compare its notes with the remotely saved ones. If there exists a historic revision in which the note used to be identical, it could be updated safely (like git fast-forward). Even if that is not in revision histories, we only have to check the differences after the revision that both devices commonly have. This is like git's conflict resolving method. So, We have to make the database again like an enlarged git repo if you want to solve the root of the problem.

README_cn.md

@@ -113,7 +113,6 @@ Note: 正在征集更多搭建方法！目前在讨论的有 [使用 fly.io](htt
 - 没有类似“exclude_folders”的配置。
 - 同步时，文件按修改时间进行比较，较旧的将被较新的文件覆盖。然后插件检查冲突，如果需要合并，将打开一个对话框。
 - 数据库中的文件在罕见情况下可能会损坏。当接收到的文件看起来已损坏时，插件不会将其写入本地存储。如果您的设备上有文件的本地版本，则可以通过编辑本地文件并进行同步来覆盖损坏的版本。但是，如果您的任何设备上都不存在该文件，则无法挽救该文件。在这种情况下，您可以从设置对话框中删除这些损坏的文件。
-- 如果您的数据库看起来已损坏，请尝试 "Drop History"（“删除历史记录”）。通常，这是最简单的方法。
 - 要阻止插件的启动流程（例如，为了修复数据库问题），您可以在 vault 的根目录创建一个 "redflag.md" 文件。
 - 问：数据库在增长，我该如何缩小它？
     答：每个文档都保存了过去 100 次修订，用于检测和解决冲突。想象一台设备已经离线一段时间，然后再次上线。设备必须将其笔记与远程保存的笔记进行比较。如果存在曾经相同的历史修订，则可以安全地直接更新这个文件（和 git 的快进原理一样）。即使文件不在修订历史中，我们也只需检查两个设备上该文件的公有修订版本之后的差异。这就像 git 的冲突解决方法。所以，如果想从根本上解决数据库太大的问题，我们像构建一个扩大版的 git repo 一样去重新设计数据库。

README_ja.md

@@ -84,7 +84,6 @@ Self-hosted LiveSync用にWebClipperも作りました。Chrome Web Storeから
 # さらなる補足
 - ファイルは同期された後、タイムスタンプを比較して新しければいったん新しい方で上書きされます。その後、衝突が発生したかによって、マージが行われます。
 - まれにファイルが破損することがあります。破損したファイルに関してはディスクへの反映を試みないため、実際には使用しているデバイスには少し古いファイルが残っていることが多いです。そのファイルを再度更新してもらうと、データベースが更新されて問題なくなるケースがあります。ファイルがどの端末にも存在しない場合は、設定画面から、削除できます。
-- データベースが変。そういうときは、いったんデータベースをDrop Historyのapply and sendで再初期化してみてください。だいたい直ります。
 - データベースの復旧中に再起動した場合など、うまくローカルデータベースを修正できない際には、Vaultのトップに`redflag.md`というファイルを置いてください。起動時のシーケンスがスキップされます。
 - データベースが大きくなってきてるんだけど、小さくできる？→各ノートは、それぞれの古い100リビジョンとともに保存されています。例えば、しばらくオフラインだったあるデバイスが、久しぶりに同期したと想定してみてください。そのとき、そのデバイスは最新とは少し異なるリビジョンを持ってるはずです。その場合でも、リモートのリビジョン履歴にリモートのものが存在した場合、安全にマージできます。もしリビジョン履歴に存在しなかった場合、確認しなければいけない差分も、対象を存在して持っている共通のリビジョン以降のみに絞れます。ちょうどGitのような方法で、衝突を解決している形になるのです。そのため、肥大化したリポジトリの解消と同様に、本質的にデータベースを小さくしたい場合は、データベースの作り直しが必要です。
 - その他の技術的なお話は、[技術的な内容](docs/tech_info_ja.md)に書いてあります。

docs/settings.md

@@ -10,7 +10,7 @@ If you feel something, please feel free to inform me.
 |   🛰️   | [Remote Database Configurations](#remote-database-configurations) |
 |   📦   | [Local Database Configurations](#local-database-configurations)   |
 |   ⚙️   | [General Settings](#general-settings)                             |
-|   🔁   | [Sync Settings](#sync-settings)                                     |
+|   🔁   | [Sync Settings](#sync-settings)                                   |
 |   🔧   | [Miscellaneous](#miscellaneous)                                   |
 |   🧰   | [Hatch](#miscellaneous)                                           |
 |   🔌   | [Plugin and its settings](#plugin-and-its-settings)               |
@@ -74,14 +74,6 @@ If you have something troubled with other devices, you can protect the vault and
 Delay database update until raise replication, open another file, window visibility changed, or file events except for file modification.  
 This option can not be used with LiveSync at the same time.
 
-### Garbage check
-This plugin saves the file by splitting it into chunks to speed replication up and keep low bandwidth.
-
-They share the chunk if you use the same paragraph in some notes. And if you change the file, only the paragraph you changed is transferred with metadata of the file. And I know that editing notes are not so straight. Sometimes paragraphs will be back into an old phrase. In these cases, we do not have to transfer the chunk again if the chunk will not be deleted. So all chunks will be reused.
-
-As the side effect of this, you can see history the file.
-
-The check will show the number of chunks used or retained. If there are so many retained chunks, you can rebuild the database.
 
 ### Fetch rebuilt DB.
 If one device rebuilds or locks the remote database, every other device will be locked out from the remote database until it fetches rebuilt DB.
@@ -242,31 +234,6 @@ But, there's no problem even if you leave it as it is.
 ### Verify and repair all files
 read all files in the vault, and update them into the database if there's diff or could not read from the database.
 
-### Sanity check
-Make sure that all the files on the local database have all chunks.
-
-### Drop history
-Drop all histories on the local database and the remote database, and initialize When synchronization time has been prolonged to the new device or new vault, or database size became to be much larger. Try this.
-
-Note: When CouchDB deletes entries, to merge confliction, there left old entries as deleted data before compaction. After compaction has been run, deleted data are become "tombstone". "tombstone" uses less disk, But still use some. 
-
-It's the specification, to shrink database size from the root, re-initialization is required, even it's explicit or implicit.
-
-Same as a setting passphrase, database locking is also performed.
-
-
-- Drop and send (Same as "Apply and send")
-1. Initialize the Local Database and set (or clear) passphrase, put all files into the database again.
-2. Initialize the Remote Database.
-3. Lock the Remote Database.
-4. Send it all. 
-
-- Drop and receive (Same as "Apply and receive")
-1. Initialize the Local Database and set (or clear) the passphrase.
-2. Unlock the Remote Database.
-3. Retrieve all and decrypt to file.
-
-
 ### Suspend file watching
 If enable this option, Self-hosted LiveSync dismisses every file change or deletes the event.
 
@@ -274,15 +241,6 @@ From here, these commands are used inside applying encryption passphrases or dro
 
 Usually, doesn't use it so much. But sometimes it could be handy.
 
-### Reset remote database
-Discard the data stored in the remote database.
-
-### Reset local database
-Discard the data stored in the local database.
-
-### Initialize local database again
-Discard the data stored in the local database and initialize and create the database from the files on storage.
-
 ## Plugins and settings (beta)
 
 ### Enable plugin synchronization

docs/settings_ja.md

@@ -70,22 +70,6 @@ End to End 暗号化を行うに当たって、異なるパスフレーズで暗
 - ファイルの修正以外のファイル関連イベント
 このオプションはLiveSyncと同時には使用できません。
 
-### Auto Garbage Collection delay
-Self-hosted LiveSyncはノートの変更時、ノートをmarkdownの構造を鑑みてチャンクに分割し、ファイルの情報と更新があったチャンクのみ保存していきます。この際、古いチャンクの削除は行いません。  
-そのため、使わなくなったチャンクをどこかのタイミングで消去する必要があります。  
-ただし、このチャンクはチャンクの内容から作成されるため、同一の内容からは同一のチャンクが作成され、同じノートだけではなく、すべてのノートから共有されます。これによってデータベースの使用容量とデバイス‐サーバー間での転送量を削減しています。  
-執筆を繰り返す上で、元の文書に戻したりすることもあるため、一概に「すぐに不要になる」とは言い切れません。そこで、プラグインはObsidianを開いたまま操作しなくなってからこの設定値秒後、まとめて使用していないチャンクを削除します。  
-この処理をGarbage Collectionと呼んでいます。  
-この作業はすべてのファイル変更の反映を停止して一気に行う必要があります。そのため、一時的にObsidianの動作がかなり重くなります。
-
-
-Obsidianでのファイル操作が終わってから指定秒数が経過した際に実行されます。  
-デフォルト値は300秒です。  
-※ごく初期は30秒でした。初期から使用されている方は、是非300秒ぐらいまで伸ばしてください。ストレスが違います。
-
-### Manual Garbage Collect
-上記のGarbage Collectionを手動で行います。
-
 ### minimum chunk size と LongLine threshold
 チャンクの分割についての設定です。  
 Self-hosted LiveSyncは一つのチャンクのサイズを最低minimum chunk size文字確保した上で、できるだけ効率的に同期できるよう、ノートを分割してチャンクを作成します。  
@@ -223,16 +207,6 @@ Self-hosted LiveSyncはPouchDBを使用し、リモートと[このプロトコ
 ### Verify and repair all files
 Vault内のファイルを全て読み込み直し、もし差分があったり、データベースから正常に読み込めなかったものに関して、データベースに反映します。
 
-### Sanity check
-ローカルデータベースに保存されている全てのファイルが正しくチャンクを持っていることを確認します。
-
-### Drop history
-データベースに記録されている履歴を削除し、データベースを初期化します。  
-新しい端末や新しいVaultへの同期にやたらと時間がかかったり、データベースサイズが肥大化したりしてきた際に使用してください。  
-備考:CouchDBは、データを削除する際、衝突の解決のために、削除した痕跡を保存します。そのため、Garbage Collectしていたとしても、データは必ず増え続けます。  
-パスフレーズ設定と同様に、完全に同期されているのであれば、データを失う可能性は低いです。  
-また、同様にデータベースのロック等の処理も行われます。
-
 - Drop and send
 デバイスとリモートのデータベースを破棄し、ロックしてからデバイスのファイルでデータベースを構築後、リモートに上書きします。
 - Drop and receive
@@ -246,20 +220,6 @@ Vault内のファイルを全て読み込み直し、もし差分があったり
 ### Suspend file watching
 ファイルの更新の監視を止めます。
 
-
-これ以降の操作は、暗号化設定のApplyや、Drop Historyで行われる処理を手動で行うためのオプションです。
-
-あまり使用することはありませんがいざというときに使用します。
-
-### reset remote database
-リモートのデータベースを破棄します。
-
-### reset local database
-ローカルのデータベースを破棄します。
-
-### initialize local database again
-デバイスのデータベースを破棄し、実ファイルから再度データベースを構築します。
-
 ### Corrupted data
 ![CorruptedData](../images/corrupted_data.png)