Kimura SCM

Appearance

Change Lists ​

A change list is a named group of file operations (adds/edits/deletes/locks) that you plan to submit together to the server.

Change lists are the main way you:

  • keep related work together,
  • describe what you changed (for teammates and audit/history),
  • and submit updates to a repository/branch as one unit.

How Change Lists Fit Into The Workflow ​

In Kimura SCM, your typical loop looks like:

  1. Work in a workspace mapped to a repository/branch.
  2. Make file operations locally (mark for edit, add, delete, lock, move/rename).
  3. Organize those operations into one or more change lists.
  4. Submit a change list to update the server history.

What A Change List Contains ​

A change list contains:

  • a description (what the change is for),
  • and the set of pending file operations you’ve made in your workspace.

It does not directly define “where” changes go; the target repository/branch is determined by your repository links (repository map) for each file path.

One Change List Can Span Multiple Repositories ​

If your workspace maps multiple local folders to different repositories (or different branches), a single change list can contain file operations from all of those mappings.

The workspace and UI usually hide this detail: you still see “one change list”, but when you submit it Kimura applies each file operation to the repository/branch that owns that file’s path via the repository map.

If you need to understand where a specific file operation will go, check its repository link/mapping for that path.

Change Lists And History (CL#) ​

After a change list is submitted, it becomes part of the server’s record. In History you’ll see:

  • CL#: the change list number associated with a revision entry.

Attachments (Supporting Docs) ​

Change lists can include attachments: supporting files like review notes, test reports, telemetry, or binaries. Attachments are a good place to keep context for peers and LLMs alongside the change itself. See Attachments and Supporting Docs.

Change List Revisions (Local Checkpoints) ​

Change lists can also have local revisions: saved snapshots of your pending operations and description. This lets you checkpoint work-in-progress and switch between versions of the same change list without creating separate repository branches.

In the Visual Client, right‑click a change list and use:

  • Save local revision
  • Browse local revisions (and optionally Switch to this revision)

Internally, these local revisions are stored as local stashes, but they are treated as “change list revisions” and are hidden from the normal Stash list.

How This Feels Like Git Branches (And How It’s Different) ​

This can feel branch-like because you can keep multiple alternative versions of your work and switch between them.

One benefit of using change lists (and change list revisions) for work-in-progress is that you can often stay on the same shared branch as everyone else while still organizing and communicating your intended changes. This helps maintain visibility and coordination:

  • declare what you’re working on (via the change list description and visible pending operations),
  • anticipate conflicts earlier (others can see locks/active operations),
  • and merge/sync earlier instead of long-running isolated branch work.

Key differences from Git branches:

  • It does not create a new server branch or separate repository history.
  • It’s a local workflow feature for pending operations in your workspace/change list.
  • When you switch revisions, the workspace may need to overwrite pending operations and local file changes (the UI can offer to back up your current state into a separate stash first).

Change Lists, Permissions, And Why Actions May Be Missing ​

Submitting requires permission to write to the target repository/path. If you can see files but can’t submit or edit, it’s often a group access issue.

Stashing A Change List ​

If you’re not ready to submit, you can stash a change list:

  • Local stash: only on your machine.
  • Remote stash: stored on the server and may be shareable depending on stash access controls.

Resolving Changes Against Newer Revisions ​

When files in a pending change list are no longer at the latest revision, a merge resolution session gives you a separate place to prepare and review the merged results before applying them to the change list.