Access control in subforge is layered: grants can be made at the workspace level (covering all repos inside it) or at the individual repo level. Both use the same roles.
Every grant carries one of three roles:
A more permissive grant always wins. If you have read+write at the workspace level and are added as read-only on a specific repo, you still get read+write on that repo.
Workspace-level — grants access to every repo in the workspace at once. Useful for a core team that needs access to everything. Managed from the workspace's Members tab.
Repo-level — grants access to one specific repo only. Useful for contractors, guests, or anyone who should only see part of a workspace. Managed from the repo's Settings tab.
In both cases, you can grant access to an individual user or to a whole group.
Every workspace has an owner (the user who created it). The owner always has full read+write access to all repos and cannot be removed. Personal workspaces are owned by the user they belong to.
Visibility is toggled on the repo's Settings tab by the workspace owner or admin.
A user can access a private repo if any of the following apply:
A group can be added as the grantee at either the workspace or repo level. Every current member of the group gets the assigned role. The access is dynamic — adding someone to the group immediately grants the role; removing them immediately revokes it.
By default, access is granted at the repository level — a collaborator can read or commit anywhere in the repo. To restrict specific paths, commit a CODEOWNERS file to the repository root. subforge reads it on each authz update and generates per-path SVN authz rules automatically, so artists can be limited to /Art and engineers to /Source within a single repo.
subforge is in beta — tell us what's broken, confusing, or missing. Goes straight to the team.