Skip to content

Collaboration & files

Working with other people — and with their machines. These guides cover how a change leaves your laptop, gets reviewed, and lands on a shared lane, plus the file-shaped problems that come with a team: locking unmergeable binaries, coordinating a change across repositories, and carrying large assets without an LFS bolt-on.

Built and tested; release evidence remains open

This section is the networked layer: clone over the wire, tovio sync, the Forge, proposals, lane protection, locks, and cross-repo changes. Networked sync (clone/push/pull) and file locking are done; the Forge collaboration server (proposals, review, lane protection, connection ACL, authenticated REST, locking, webhooks) is built and passes its hermetic --features tls test suite. Production binaries passed the distinct-Docker-host exercise under a real operator CA. Public-release, broader HA/load, hosted-parity, and external evidence remain Phase 5 gates.

What you can do here

  • Team workflows & diagrams — the visual map: team topology, the daily loop, the land gate, the review ping-pong, and a full feature shipping end to end.
  • A team on one feature — how a whole team builds one large feature off to the side on a shared lane, how several such teams run in parallel, and how a feature is promoted.
  • Clone and sync — pull a repository from a Forge or a peer, then keep in step with tovio sync. One command does push and pull, and divergence reconciles itself — there is no "rejected" or "diverged" to fight.
  • Propose and review — open a change for review, walk the proposal lifecycle, and review changes that touch files you may not be cleared to read.
  • Lane protection — put a landing gate in front of a shared lane: required reviews, required checks, cleared-reviewer coverage, and path-scoped change control.
  • Lane workflows — enforce a branching model rather than documenting one. Declare which (source → target) lane transitions are legal — "a feature lane may not land onto main" — from a shipped preset like Git Flow or your own .toml.
  • File locking — take an exclusive or advisory lock on a binary that can't be merged, so two people never overwrite each other's work.
  • Cross-repo changes — group one feature's changes across several repositories into a meta-change that lands atomically or in a defined order.
  • Large binaries — commit big assets directly. FastCDC chunking gives you binary parity with no LFS, no smudge filters, and no separate store.

Before you start

  • New to TOVIO? Learn the local loop first in the getting-started tutorials, then come back when you're ready to share work.
  • Want the why behind auto-reconciling refs and conflicts-as-data? Read the core concepts.
  • Running the server side? The on-premise guides cover deploying a Forge.

How this fits together

A typical team flow threads these pages in order: you clone a repo, do local work, sync it up, propose it for review, and it lands through the lane-protection gate. Locking, cross-repo changes, and large binaries are the file-shaped tools you reach for when a particular job needs them.

Last reviewed September 9, 2026

Suggest an improvement to this page Not for security reports — see disclosure