Record file root sync conflicts

This commit is contained in:
Eric Wendland 2026-05-21 01:40:50 +02:00
commit 475c6a4a2a
8 changed files with 324 additions and 14 deletions

View file

@ -134,13 +134,16 @@ pull authorized remote file-root tree metadata with `geth cas root sync <node>
remote CAS tree bytes and records a peer-qualified remote root whose path is
`remote:<node>:<name>` without applying files. File roots also participate in
the daemon background live-sync loop through authorized `cas-tree:<name>`
watermarks. `geth cas root apply <root> --to <path>` is the first conservative
watermarks. Repeated remote file-root syncs retain the previous imported remote
tree as the base and compare base/local/remote tree state. When both local and
remote roots changed, geth records durable concurrent edit, delete/edit, or
divergent rename conflicts instead of applying remote content. `geth cas root
apply <root> --to <path>` is the first conservative
materialization path: it creates missing files and directories from the CAS tree,
does not delete extra local files, does not overwrite differing local files, and
records conflicts for manual resolution. The daemon also has durable local
file-conflict records with explicit resolution choices; future cross-node file
sync will extend those records instead of silently applying ambiguous remote
changes.
file-conflict records with explicit resolution choices; richer three-way apply
will extend those records instead of silently applying ambiguous remote changes.
As a bootstrap network path, `geth cas fetch <node-id> <hash>` dials an
imported signed peer card over the daemon-owned Iroh control ALPN. The serving
@ -149,9 +152,8 @@ then reduces local auth ops and requires `cas.fetch` on `resource:cas:local`
before returning blob bytes. The requester verifies that the returned bytes hash
to the requested BLAKE3 CAS hash before storing them. Successful fetches update
durable local provider metadata keyed by CAS hash and peer node, which can be
inspected through `geth cas providers <hash>`. Iroh-blobs, encrypted blobs,
richer cache policies, cross-node file roots, and automatic conflict detection
are future work.
inspected through `geth cas providers <hash>`. Iroh-blobs provider/fetch
integration and richer three-way file application are future work.
`geth-db` currently registers local SQLite paths as DB resources and reports
local-only sync status plus a read-only SQLite schema summary/hash. It also

View file

@ -556,15 +556,15 @@ and future group key evolution.
- `[ ]` Future completion adds a richer three-way apply using base/local/remote
trees for automatic safe updates and deletes.
- `[~]` Conflict handling.
- `[x]` Conflict handling.
Acceptance criteria:
- `[x]` Conflicts are represented as durable metadata.
- `[x]` CLI/control can record, list, and choose a resolution for local
conflict metadata.
- `[x]` Tests cover local concurrent edit conflict record/list/resolve.
- `[ ]` Future sync records conflicts automatically from base/local/remote
- `[x]` Future sync records conflicts automatically from base/local/remote
tree comparisons.
- `[ ]` Tests cover automatic concurrent edit, delete/edit, and rename
- `[x]` Tests cover automatic concurrent edit, delete/edit, and rename
conflict detection.
- `[ ]` Keyhive-like convergent capabilities.