Kimura SCM

Appearance

Permissions And Group Access ​

In Kimura SCM, what you can see and do is mostly determined by:

  • which user you are signed in as,
  • which groups you belong to,
  • and the access rules configured for those groups.

These permissions affect repositories, folders, and files, and they also influence which UI actions are enabled.

Access Levels ​

In Administration → Groups, the UI exposes these access levels:

  • No Access
  • Read access
  • Write access
  • Super user access

What each level means in practice depends on your workflow, but generally:

  • Read: you can see and sync/get content, but you can’t submit changes.
  • Write: you can create and submit changes (edit/add/delete/lock) where allowed.
  • Super user: elevated rights for that scope (often used for admins/power users).

Scope: Repository, Directory, File ​

Group access rules can apply at different scopes:

  • a whole repository,
  • a directory (folder) inside a repository,
  • or an individual file.

How Group Membership Changes Your Effective Access ​

A user can belong to multiple groups. Each group can grant access to different parts of a repository tree.

In practice, this often means your effective access is a combination of group rules, for example:

  • You might get broad read access from a general group (like Developers), and then receive extra write access to specific folders from a specialized group (like Build).
  • Another group might elevate access to a single sensitive folder or file (for example a protected config or binary asset).

This is how teams avoid giving everyone full write access while still allowing the right people to work in the right areas.

This is how teams implement patterns like:

  • “Everyone can read the whole repo, but only the Build group can write to /Release.”
  • “Only one group can edit a specific binary file.”

How The UI Reflects Permissions ​

Permissions typically show up as:

  • missing or disabled right‑click actions,
  • items not appearing in the workspace tree,
  • submit/revert/lock actions failing or being unavailable.

Tip: in the Visual Client you can enable Settings → Show access right on directories to help spot access differences in the workspace view.

Repository links (repository map) define where a local path belongs (repository/branch). They do not grant permissions.

If a path is mapped but you still can’t see or change it, it’s usually a group access issue.

Permissions And Common Operations ​

  • Sync/Get: usually requires read access to the target path.
  • Edit/Add/Delete/Lock: usually requires write access to the target path.
  • Submit change lists: requires write access for every file operation being submitted (possibly across multiple repositories if your workspace maps multiple repos).

Remote Stashes And Permissions ​

Remote stashes have their own visibility/modification controls (for example Owners/Modify/Viewers), but repository access rules can still restrict what you can do after retrieving the stash.