Keep building while a conflict is open

Because a conflict does not rewrite your files, an open conflict is a state you can live in. Commit, switch lanes, sync, keep going. The conflict travels with the change rather than pinning you in place.

The buildable view

Tooling that needs to ask "does this build?" reads a materialized view: each conflict entry is rendered as a chosen clean side so the tree can be assessed without being resolved. It is a derived projection — never stored, never hashed, never something you can accidentally commit.

Switching lanes with a conflict open

This works. Your dirty edits are snapshotted and three-way merged onto the destination; disjoint edits carry over automatically, and overlapping ones become ordinary conflict objects like any others. Existing conflicts come along too.

There is one refusal, and it is narrow: if a path is already conflicted in your working change and the destination changed that same path, the switch stops before touching any lane metadata. Nesting a conflict inside a conflict as a content side would not be sound, so it declines rather than inventing an answer.

Depending on someone else's conflict

This is where the boundary sits. Your own open conflict is your business; pulling in someone else's unresolved conflict as a dependency is refused, with TVO-CONFLICT-004. You would be building against a question nobody has answered yet.

There is a deliberate way through it:

tovio sync --isolate

This builds each conflicted dependency at its last-known-clean version — the most recent conflict-free ancestor of that path. Non-conflicted paths use current content as usual. Each isolated path is pinned, so tovio status keeps flagging that you are on an isolated build until the upstream resolution clears it, at which point it refreshes on its own.

It is a supported way to keep moving, and it is loud about it. It is not a way to forget.

Or ask

tovio change notify <id>

Records a durable notify-intent against the change, so you hear when the author resolves it. Then re-sync.

Rebasing over a conflict

Re-parenting a change does not require a clean tree. Where content cannot auto-merge, the conflicts are stored rather than blocking, and change ids survive the rewrite so recorded resolutions still match.

Two edge cases worth knowing. An edit to a path the new base still holds conflicted is deferred, not lost — resolve the origin conflict and re-apply, or tovio undo. And a re-derivation that would leave a conflict on an exclusively-lockable path is refused outright with TVO-LOCK-002, because a binary that cannot merge would lose a write silently.

Operations that do need a clean tree

Some things genuinely cannot proceed over a conflict and say so rather than producing a result that quietly means nothing — TVO-CONFLICT-010 covers that family. Key rotation is its own case: a conflicted path cannot be re-sealed, and the rotation refuses with TVO-CONFLICT-008 instead of half-completing.

In every case the fix is the same, and the error names it: resolve the path, then retry.

tovio conflicts

tovio resolve <path>