Kimura SCM Compared To Git And Perforce

This document maps Kimura SCM concepts to rough equivalents in Git and Perforce. It is intended to help experienced users transfer mental models quickly.

These comparisons are not feature-parity claims. Different systems make different tradeoffs (distributed vs centralized, server-side policy vs local freedom, etc.).

Quick Mapping Table

Kimura SCM	Git (rough equivalent)	Perforce (rough equivalent)
Repository	Repository	Depot (or a project subtree in a depot)
Branch	Branch	Stream (or branch path)
Workspace	Working tree / clone	Client workspace
Repository links (repository map)	Multi-repo setup (submodules/subtrees) + local folder conventions	Client view mapping (what maps where)
Change list (pending)	“Index + working tree changes” before a commit	Pending changelist
Submitted change list	Commit	Submitted changelist
Merge resolution session	Conflict resolution after a merge, rebase, or cherry-pick	Resolve workflow for files in a pending changelist
Stash (local/remote)	git stash (local); “patches/shared WIP” via other tooling	Shelved changelist (closest), or a saved changelist variant
Ignore rules (.kscmignore)	.gitignore	.p4ignore (or ignore config)
Live reconcile (auto-reconcile)	git status + diff tools + manual scan	Reconcile/offline workflows + pending state
Large repositories / large files	Depends on hosting/tooling; often uses Git LFS for very large binaries	Commonly used for very large depots and binary assets
Centralization model	Distributed (centralized hosting is a workflow choice)	Centralized
Workspace metadata storage	.git directory stores full object database/history (plus index)	Workspace is mostly plain files; “have list” and history live on the server
Visibility into other users	Usually via hosting/PRs or external tooling	Strong, server-centric visibility (opened/locked files, etc.)
File locking	Typically via LFS locks or conventions	First-class locking workflows
Binary workflows	Often rely on LFS and locks; merges are usually difficult	Commonly used for binary-heavy teams (locking + centralized workflows)
Permissions / access rules	Usually enforced by server hosting (GitHub/GitLab)	Protections + stream/depot policies
File servers	No direct equivalent (closest is Git LFS for “separate file storage”)	Built-in part of the Perforce server architecture

Core Concept Comparisons

Repositories And Branches

• Git: repositories are the unit of distribution; branches are lightweight pointers inside the repo.
• Perforce: depots/paths are server-side; streams are a structured way to model branching and integration.
• Kimura: repositories and branches are server-side containers/lines of work, and your workspace is mapped to them via repository links.

Kimura repositories are designed to handle very large numbers of files, and there are no limitations on file sizes.

Workspaces

Kimura workspaces are your local working area, where you:

• sync/get file content,

• create pending operations,

• group work into change lists,

• and submit or stash.

• Git: a working tree is typically tied to one repo+branch (unless you use multiple worktrees, submodules, or a mono-repo layout).

• Perforce: a client workspace is a first-class concept, and your view mapping defines exactly what appears locally.

Kimura also provides Live reconcile (auto-reconcile) views that help you track what changed locally vs. the server (including after working offline and reconnecting), which is especially useful in very large workspaces.

Kimura workspaces also keep a local metadata database/cache to support these views (history/state/revision tracking), but they do not store full file history or all revisions locally, and they avoid a .git-style metadata folder inside the workspace tree.

Where Workspace Metadata Lives

• Kimura: workspace metadata is stored outside the workspace directory (in application data), so your workspace tree stays “clean” and only contains your project files.
• Git: repository metadata (including the object database/history) lives inside the working tree in the .git directory.
• Perforce: the source of truth (depot history and workspace mappings) lives on the server. Your local workspace is mostly plain files, with local client state managed by the client tooling rather than a .git-style folder in the workspace.

Who “Owns” The Workspace (What The Server Knows)

• Kimura: the workspace lives entirely on the client. The Kimura server does not “own” or manage your workspace state the way a Perforce server tracks client workspaces. The workspace name may be attached to operations, change lists, and stashes for tracking/visibility, but the server does not maintain a server-side “workspace spec” that defines your local view.
• Git: the server generally does not know anything about your local working tree state. Coordination happens when you push/pull and through hosting workflows (PRs, reviews), not through server awareness of your workspace.
• Perforce: the server has first-class knowledge of client workspaces (client specs/view mappings) and commonly tracks workspace-related state (what’s synced/“have”, what’s opened, who has locks). However, it does not inherently know about arbitrary local file edits that are not bound to an operation (for example files changed on disk without being opened/checked out), which is why reconcile/offline workflows exist and can be more involved.

Kimura workspaces also emphasize visibility:

• you can see other users’ activity through the Active file operations view,
• and through visual indicators in the workspace tree (for example items showing active operations, locks, or “not at latest revision” state).

File Locking And Binary Workflows

Kimura supports file locking as a first-class workflow, which is especially important for binary files where merges are difficult.

• Git: many teams rely on conventions and/or Git LFS locks to manage binary contention; visibility of “who is working on what” often lives in hosting tools and PR workflows.
• Perforce: centralized workflows and first-class locking are common patterns for binary-heavy projects.
• Kimura: the UI and server workflows emphasize coordination (locks + active operations visibility) so teams can avoid conflicting edits and anticipate contention earlier.

Repository Links (Repository Map)

Repository links are one of the biggest “mental model shifts”:

• Git: there is no built-in “map multiple repositories/branches into one unified workspace tree” feature. The closest patterns are:
  • multiple clones in sibling folders,
  • submodules (repo pointers inside a parent repo),
  • subtrees (vendoring another repo into a directory),
  • or a mono-repo.
• Perforce: repository links feel very similar to a client view mapping: it defines what local paths map to what server-side sources.

Kimura repository links map local path → (repository, branch). This can make a workspace look like one tree even when it spans multiple repositories/branches.

Change Lists

Kimura change lists are how you group pending operations and describe what you intend to submit.

• Git: closest mental model is “what will go into the next commit”, but Git lets you stage/commit at a very fine granularity without an explicit server-side pending changelist concept.
• Perforce: this maps cleanly to pending/submitted changelists.

Kimura can also save local revisions of a change list (stored internally as local stashes), which can feel “branch-like” for work-in-progress without creating a separate server branch.

Merge Resolution Sessions

A merge resolution session is a separate, resumable area for preparing pending edits in a change list against newer revisions. It keeps the prepared results separate from the change list until every item is resolved and you apply them together.

• Git: the closest equivalent is resolving conflicts as part of a merge, rebase, or cherry-pick, then staging the resolved files before continuing the operation.
• Perforce: the closest equivalent is resolving files in a pending changelist.
• Kimura: the resolution plan is a persistent session scoped to one change list. This gives you a place to review each result before applying the completed group to pending work.

The first beta scope is content merge decisions for pending edits that need to advance to newer revisions. It is not a general replacement for every Git or Perforce integration workflow.

Stashes

Kimura stashes save a snapshot of a change list’s pending work.

• Git: git stash is local-only by default; sharing typically involves other workflows (branches, patches, PRs).
• Perforce: shelving is often used as “shareable WIP” and review input; it’s the closest match to remote stashes.

Ignore Rules

Kimura ignore rules are stored in .kscmignore at the root of each repository mapping and are versioned like normal repository files.

• Git: .gitignore patterns control what appears as untracked/ignored.
• Perforce: .p4ignore and ignore configuration serve a similar purpose.

Permissions And Group Access

• Git: permissions are typically enforced at the repository hosting layer (who can read/push/merge), not in the local tool.
• Perforce: protections and depot/stream policies are central and explicit.
• Kimura: access is primarily enforced via users, groups, and repository/folder/file access rules, which in turn affects what actions are available in the UI.

File Servers

Kimura separates “coordination” from “file content transfer”: the server manages history and permissions; file servers handle file content movement.

• Git: file content is typically served directly via the Git server protocol (unless you use add-ons like Git LFS).
• Perforce: file content storage/transfer is part of the Perforce server.

This also highlights a centralized vs. decentralized distinction:

• Kimura remains centralized for “truth” (history, permissions, change lists),
• but file servers provide a way to scale and somewhat decentralize file distribution (multiple endpoints, optional standalone file servers).