Skip to main content
Use Code Storage as the version control system for a product’s files. Your application uses the SDK to store each change as a commit, to read one exact version, and to show history. A user edits the files through your product interface and never uses Git. Your application validates the complete file set, saves it, applies that exact version, and records it as the active revision. The active revision is the exact commit that the product currently uses.

Provision the managed repository

For each product, create one managed repository in Code Storage. Save the repository id on your product record, so a later request finds the right repository. The examples use products and productFiles for services that you own.

Create the first active revision

Build and validate the complete file set before you save it. Save the files as one commit. Apply that exact commit, then record it as the active revision.
Update activeRevision only after the apply step succeeds.

Validate and save a user edit

Build the complete file set that would result from the edit. Validate all files before you save any of them. If validation fails, return the errors and keep the active revision unchanged.
A conflict means that another editor saved first. Reload the current files and ask the editor to resolve the conflict. Do not save the old file set again without review. An identical candidate file set returns precondition_failed; treat it as success with no new revision. After a timeout, the commit can still exist. Do not resend the same request. Read the current head again. Rebuild the candidate file set from the current product state. Send a new commit with the new head as expectedHeadSha.

Apply the saved version

After a successful save, read the complete file set by its commit SHA. Apply only those files. Mark the commit as active only after the apply step succeeds.
Do not apply files that you have not saved. If the apply step fails, keep the prior active revision. Fix the apply service and retry the same commit SHA.

Show history and undo a change

Keep repository details behind your product interface. Use listCommits and getCommitDiff to show who changed the product and what changed.
Use restoreCommit to create a new commit from an earlier version. Apply and record the new commit, not the old commit that supplied its files.
Use the same failure rule for an undo. If the apply step fails, record the restored commit as the repository head and keep the prior active revision.

Limit service access

Keep the organization private key on your server or in a secret manager. Give each product service a temporary token for one managed repository. Grant only the permissions that the service needs. Use a separate repo:write token when the provisioning service creates a managed repository. See Authentication & Security for token details. Use Load Agent Memory when an agent reads and updates selected memory files without human approval.