Sync and continuity
How Bowline captures your work as you go with near-continuous snapshots, instead of last-writer-wins file sync.
Bowline keeps your work safe with near-continuous snapshots, not last-writer-wins file copying. It records local writes, coalesces noisy file events, syncs source-like state eagerly, and preserves both sides when offline work diverges. This page explains what that means for your day-to-day work.
Continuity, not file sync
Consumer file sync tools treat the newest write as the truth and overwrite the rest. That's fine for photos and documents. It's dangerous for code, where two machines can each hold work you don't want to lose.
Bowline instead advances a project through Workspace Snapshots. As you work, your writes collect in a Machine Overlay and become a new snapshot when they're safe to merge. When two sides diverge in a way Bowline can't merge safely, it preserves both rather than picking a winner. The result is continuity: your in-progress work follows you, and nothing is silently overwritten.
What syncs
The accepted workspace root, normally ~/Code, is the sync boundary. Inside it,
Bowline syncs source-like state and skips dev junk. Repo, package, and monorepo
boundaries don't limit what syncs; the workspace root does.
| Category | Syncs by default? | Examples |
|---|---|---|
| Source-like work | Yes | Source files, configs, notes, fixtures, repros. |
| Env files | Yes | .env, .env.local, .env.* under the root. |
| Opaque Git state | Yes | .git/ bytes, synced as encrypted state. |
| Generated output | No | Build output, compiled artifacts. |
| Dependencies | No | node_modules, vendored packages. |
| Caches | No | Tool and package-manager caches. |
| Explicit local-only | No | Paths you mark local-only via path policy. |
Ignore rules are evidence for how Bowline classifies a path, not the final authority. Git-ignored but source-like state (env files, local notes, repros, and fixtures) can still sync when it isn't generated, a dependency, a cache, or explicitly local-only. You shape this with path policy.
Immediate sync
On a fresh trusted device or agent host, Bowline starts syncing the whole
~/Code tree immediately. Once the project is present, it behaves like an
ordinary local directory through aggressive local caching.
This is why a new machine is useful right away: the codebase appears as normal files, and your editor, terminal, and agent tools operate on the local tree.
Working offline
When you work offline, your writes still collect locally as a Machine Overlay. When the machine reconnects, Bowline advances the Workspace Head with any changes that merge safely. If your offline work diverges from newer work elsewhere, Bowline opens a Sync Conflict and preserves both sides instead of overwriting either.
You don't run a sync command. The daemon records writes, coalesces noisy file
events, and advances snapshots in the background. Use bowline status --root ~/Code to see sync, materialization, and freshness state
at any time.
Inspecting sync state
Bowline makes sync observable rather than mysterious. Every meaningful transition is an event, and status reads from those events.
bowline status --root ~/Code --project <path>reports sync state, materialization, freshness, and attention state for the current project. Add--watchto stream changes.bowline events --root ~/Codelists recent workspace events.- To understand why a path syncs, materializes, stays local, or needs review,
check your project's
.bowlineignoreand path policy classification, then confirm current behavior withbowline status.
Next steps
- Conflicts: how Bowline preserves and repairs divergent work.
- Path policy: control what syncs with
.bowlineignore. - Status and health: read workspace and project state.
- Architecture: the daemon, control plane, and byte plane underneath.