eric/geth
Watch
1
0
Fork
You've already forked geth
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Record file root sync conflicts

Browse source
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
Download patch file Download diff file Expand all files Collapse all files

16
docs/architecture.md
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