Working as a team

A Cxddie project is a git repo, so a team shares it the way it shares code: through a remote such as GitHub, GitLab or Gitea. This works the same for every CAD system, because every workspace saves its model to a file in the repo.

SyncCopy Anchor Link

Click ⇅ next to the project's name. The first time, Cxddie asks for the remote's URL (an empty repo your team shares). Each sync:

1. fetches the team's commits,
2. merges them into your main checkout,
3. pushes your commits, including workspaces you kept.

Sync needs a clean main checkout, and git must already be able to reach the remote (an SSH key, or a credential helper for HTTPS).

Files changed on both sidesCopy Anchor Link

CAD files are binary, so git can't combine two people's edits to the same model. When a file changed both in your project and on the remote, Cxddie doesn't pick one. Nothing is merged; instead it shows each file with who changed it and lets you choose the remote's version, yours, or both. Both keeps yours at the original path and adds the remote's next to it (model.origin.FCStd), so you can open the two and combine them by hand or with an agent.

Replaying a workspace's changes (experimental)Copy Anchor Link

Two versions of a binary CAD file can't be combined, but what an agent did can be done again. Cxddie records every change agents make through its tools (.cxddie-meta/<document>.ops.jsonl). When you keep a workspace whose CAD file also changed in the project, the dialog offers Replay this workspace's changes onto the project's version:

1. the workspace takes the project's version of the file,
2. Cxddie runs the workspace's recorded changes on it again, in the workspace's CAD session, and saves,
3. nothing is merged yet: check the model, then Keep again, which now merges without asking.

A change can mean something different on a different model (a name already taken, an edge that moved), which is why you check before keeping. If a change fails, the workspace is put back exactly as it was. Replay is offered for the workspace's own document when its changes were recorded, and not after an agent switched to another document.

Keeping a workspace works the same way when the project moved on since the workspace started. See Fan out, compare, keep.

Reviewing CAD changesCopy Anchor Link

A diff of a binary CAD file says nothing, so whenever a workspace's model is saved, Cxddie writes two small files next to it, which are committed along with it:

• .cxddie-meta/<document>.json: the model's objects (names, types, bounding boxes) and its overall size and volume. A pull request's diff shows what changed, for example "Tower added, height 5 → 50 mm".
• .cxddie-meta/<document>.png: a thumbnail. GitHub and GitLab show image changes side by side.

They come from the same tools agents use, so every CAD system gets them, and the thumbnail is Cxddie's own render of the model's mesh, so an unchanged model gives an identical image. The Changed in both places dialog uses them to show both versions side by side with their sizes. A document's sidecars always follow the choice made for the document.

Locks: who is editing whatCopy Anchor Link

When git-lfs is installed and the remote supports LFS locks (GitHub, GitLab and Gitea do), a new workspace locks its CAD file on the remote. Teammates then see locked on their workspaces for that file, and a note naming who holds it, before anyone spends an afternoon on a model someone else is changing.

• Deleting a workspace releases its lock at once.
• Keeping a workspace holds the lock until your next sync has pushed the work, then releases it.
• Locks are advisory: they warn, they don't block. Cxddie doesn't mark files lockable, because git would then make them read-only and CAD apps couldn't save.

Code-CAD sources (OpenSCAD, CadQuery, build123d) are text, so they merge like code and aren't locked.