Who can access source code?

Project administrators can give project members specific kinds of access to a whole Subversion repository or any path within that repository.

Overview

You can specify access permissions for users with a given role at the repository level, or at the path level within a repository.

How you use path-based permissions will depend on whether you view permissions primarily as a way to grant access or as a way to restrict access.

Full access, with exceptions
Give your company's own employees commit access to your whole source code base, while allowing developers from contracting firms to commit only to those parts of the code base that they are expected to work on.
No access, with exceptions
Assign all developers "No access" by default, then assign each type of developer access to certain directories and files according to their responsibilities.
Note: You can control access to a path or to an individual file. This is different from normal Subversion checkout and commit operations, which are performed on directories but not individual files.

No Access

When you deny all access to a repository for a role, users with that role cannot see that the repository exists, except if:

Note: An individual user can have multiple roles. When two roles have permissions that conflict with each other, the role with the more expansive permissions takes precedence.

View Only

Users with a role that has "View Only" access to a path can browse the contents of the repository on the Web site or by connecting directly to the repository from a client, such as Tortoise, CollabNet Desktop for Eclipse, or CollabNet Desktop for Visual Studio.

View and Commit

Users with a role that has "View and Commit" permission to a path can browse and download code, and can also check code into the repository.

Wildcard-based access control and path-based permissions

You can create rules that use wilcards to control access to specific paths in a repository. See Wildcard-based access control and path-based permissions in TeamForge for more background information about wildcard and path based permissions.

Scenario 1

Controlling access to a specific path in a branch using authz rules can be very time consuming and inefficient. Assume you have three branches, [/branches/foo/build], [/branches/bar/build], and [/branches/baz/build]. If you create authz rules, you may have to write a separate rule for every branch in the repository, let alone the fact that you need to write such rules for a branch you may create in the future.

[/branches/foo/build]
@build = rw
@dev = r
[/branches/bar/build]
@build = rw
@dev = r
[/branches/baz/build]
@build = rw
@dev = r
Instead, you can write a rule using wildcards such as:
/branches/*/build
Later, you can create and assign roles to users such as "build engineers" and "developers" with "read-write" and "read-only" access permissions respectively.
Scenario 2

In this scenario, assume that there is a particular file or folder pattern that needs access control in a repository. For example, you may want to restrict all users but release managers from modifying .iso files. It is impossible to define such a rule using the authz file.

With TeamForge, you can write a rule that partially uses wildcards in file or folder names such as:
/trunk/build/*.iso
This rule applies to all files and folders that end with .iso under the path /trunk/build.
Scenario 3

In this scenario, assume that you want to control access to a particular folder no matter where the folder is in a branch. For example, you may want to control access to the “build” folder wherever it is in a repository. You can write a rule using wildcards such as:

/**/build

The "**" matches any number of folder levels in a repository. For example, this rule applies to the following paths:

/trunk/build
/branches/feature1/build
/trunk/external_module/build
/build
In addition to these scenarios, you can use wildcards to create rules that suit your requirement. A few examples of how you can create wildcard-based rules:
  • /**/*.iso - Match any .iso file anywhere in a repository.
  • /branches/RB* - Match any branch if the name starts with RB.
  • /branches/*/*.txt - Match all .txt files one level under any branch.
Notes about path-based permissions

If two paths have different permissions, the permissions on the lower-level path take effect. For example, consider a role that has "No Access" set for the path /branches/version3/users, but has "View and Commit" access to /branches/version3/users/vijay. A user with this role can:

Users with this role cannot:

Commit messages

When users monitor a repository, they receive commit announcements by email that include the resources that their role permits them to see.

Users with a "No Access" role on a repository cannot monitor that repository to receive commit messages by email.

By default, commit emails provide all the details about the commit that a logged-in user can view in the Source Code application. A repository owner can elect to have the notification emails omit most of the detail and provide only the commit ID and the committer's user name.

Toolbar button

If none of the available permissions (View Only, View and Commit, or Path-based Permissions) is selected for any repository, and none of the options under Source Code Permissions is selected, users with this role do not see the Source Code toolbar button.