AutomationView does not include a built-in version-control system. Instead, it stores your project as clean, plain-text files that work cleanly with whatever version control tool you already use - for example Git, Subversion, or Mercurial.
AutomationView has no commit, branch, clone, or "version project" command of its own. Use your existing version-control tool. This page explains why AutomationView projects work well with one.
Every part of an AutomationView project is stored as plain text:
.seq files - your Sequence programs.machine files - machine and I/O configurationWhen AutomationView generates Sequence code, it sorts object keys deterministically. This means the same logical program always produces the same text output, so a version-control tool shows only the lines you actually changed, without noisy reordering. The result is small, readable diffs that survive code review.
Because AutomationView files are plain text, your version-control tooling can present older revisions and diffs the same way it does for any other file. When the AutomationView editor supplies a historical or diff version of a .seq or .machine file - for example from the Timeline, local history, or a Git diff - the visual editors can render that snapshot.
Historical and diff snapshots open read-only. You are looking at a past revision, not an editable copy. To change anything, open the current file.
This lets you compare two revisions of a Sequence or machine visually, instead of reading raw text, while the actual version-control operations stay with your own tool.
AutomationView does not run these steps for you - perform them with your version-control tool of choice. A typical Git workflow looks like this:
git init)..seq, .machine, and Python files with a clear message.Following these practices will save you significant time when troubleshooting production issues or onboarding new team members.