Kimura SCM

Appearance

Workspaces ​

A workspace is your local working area on disk. It’s where you sync files from the server, make local edits, and manage pending work before submitting it back to the server.

Most of the Kimura SCM workflow is built around the relationship between:

  • Workspace: your local folder tree + pending operations.
  • Repository links (repository map): how workspace paths map to server repositories/branches.
  • Change lists: how you group pending operations for submit/stash.

What A Workspace Does ​

Your workspace is where you:

  • view a mapped tree of repositories/folders/files,
  • sync/get file content to a specific revision (often “latest”),
  • make file operations (add/edit/delete/lock/move/rename),
  • reconcile to see what changed locally vs. the server,
  • submit or stash work.

At a higher level, the workspace is meant to keep you aware of:

  • the state of your local files (what’s present, modified, ignored, not at latest revision), and
  • what other users are doing on the server (active operations, locks, etc.), ideally within the same repository/branch you’re working in.

Local Workspace Database (Metadata, Not File Content) ​

To keep the UI responsive and enable reconcile workflows, the workspace maintains a local database/cache of metadata such as:

  • folder history and file state,
  • current revision numbers and “not at latest revision” tracking.

This local database is not a copy of your repository’s file history:

  • it does not store the actual file contents for the repository, and
  • it does not store all historical revisions of files.

Because this metadata is stored outside of the workspace directory, your workspace folder is not “polluted” by source control internals (no .git-style directory inside your working tree).

Visibility Into Other Users’ Operations ​

Workspaces don’t just show your local files. They also provide visibility into activity happening on the server, such as operations performed by other users.

In the Visual Client, use:

  • Active file operations: shows operations being performed by users (filterable by filename/user/repository and operation type).
  • Show active operations (F3) from the workspace tree or reconcile views to jump to that tab with filters pre-filled for the selected file/folder.

Visual Indicators In The Workspace Tree ​

This visibility is also reflected directly in the workspace tree: items can show different icons and text styling to indicate state such as:

  • you have pending operations (for example checked out/added/deleted/locked), or
  • another user has an active operation affecting that item (for example a lock or checkout by someone else).

Files and folders can also indicate when they are not at the latest revision, which is a common signal that you may want to sync.

These indicators help you notice activity and avoid conflicting work without having to open the Active file operations tab first.

Live Reconcile (Auto-Reconcile) ​

The workspace continuously tracks differences between:

  • what you have locally (including pending operations), and
  • what the server considers the latest known state.

Kimura SCM is designed to keep this tracking responsive even for very large workspaces, so you can rely on Live reconcile as a “what changed?” view without manually auditing the tree.

This is reflected in the Live reconcile section of the Workspace changes tab (All/Modified/Added/Missing/Not at latest revision). If the view looks out of date, use Refresh (F5).

A workspace uses repository links (the repository map) to decide which server repository and branch each local folder belongs to.

The repository map is a set of mapping entries. Each entry links:

  • a local Path in your workspace,
  • to a server Repository,
  • and a Branch.

This is why you can have one workspace that contains multiple “top-level projects” that actually live in different repositories on the server.

Common Mapping Shapes ​

  • One repo / one branch (most common): your workspace root maps to a single repository+branch.
  • Multiple repositories: different local folders map to different repositories (for example /Engine → Engine/main, /Game → Game/main).
  • Multiple branches: different local folders map to different branches. This can be useful, but it can also be confusing—be explicit with naming and communication if you do this.

How This Affects Submitting And History ​

The repository map determines where operations go:

  • When you submit a change list, each file operation is applied to the repository/branch that owns that file’s path.
  • History views can filter by repository/branch, but from a “workspace” perspective it can feel like one unified tree.

If you ever wonder “which repo is this file in?”, check its mapping entry (or enable UI hints such as showing repository names on directories).

This mapping determines where each file operation will be submitted on the server.

File Servers: Where File Content Comes From ​

The Kimura server tracks history and permissions, but file content is transferred via file servers. When you create or use a workspace, you may choose file server endpoints (primary/secondary).

Workspaces And Permissions ​

Even if your workspace maps to a repository/path, you may not be able to see or modify it without the right access.