Access to SVN does not have specific roles
based on Licensing as is found with TFS but users are given access
to Repositories (REPO) as is appropriate for there roles
Further Details Can be found on SourceForge
HEREAs well ass access to the whole project, users
can be given a sub set of access using Path-Based
Authorization
Both Apache and svnserve are capable of granting
(or denying) permissions to users. Typically this is done over the
entire repository: a user can read the repository (or not), and she
can write to the repository (or not). It's also possible, however,
to define finer-grained access rules. One set of users may have
permission to write to a certain directory in the repository, but
not others; another directory might not even be readable by all but
a few special people. As files are paths, too, it's even possible
to restrict access on a per file basis.
Do You Really Need Path-Based Access
Control?
A lot of administrators setting up Subversion for
the first time tend to jump into path-based access control without
giving it a lot of thought. The administrator usually knows which
teams of people are working on which projects, so it's easy to jump
in and grant certain teams access to certain directories and not
others. It seems like a natural thing, and it appeases the
administrator's desire to maintain tight control of the
repository.
Note, though, that there are often invisible (and
visible!) costs associated with this feature. In the visible
category, the server needs to do a lot more work to ensure that the
user has the right to read or write each specific path; in certain
situations, there's very noticeable performance loss. In the
invisible category, consider the culture you're creating. Most of
the time, while certain users shouldn't be committing changes to
certain parts of the repository, that social contract doesn't need
to be technologically enforced. Teams can sometimes spontaneously
collaborate with each other; someone may want to help someone else
out by committing to an area she doesn't normally work on. By
preventing this sort of thing at the server level, you're setting
up barriers to unexpected collaboration. You're also creating a
bunch of rules that need to be maintained as projects develop, new
users are added, and so on. It's a bunch of extra work to
maintain.
Remember that this is a version control system!
Even if somebody accidentally commits a change to something she
shouldn't, it's easy to undo the change. And if a user commits to
the wrong place with deliberate malice, it's a social problem
anyway, and that the problem needs to be dealt with outside
Subversion.
So, before you begin restricting users' access
rights, ask yourself whether there's a real, honest need for this,
or whether it's just something that “sounds good” to an
administrator. Decide whether it's worth sacrificing some server
speed, and remember that there's very little risk involved; it's
bad to become dependent on technology as a crutch for social
problems.[61]
As an example to ponder, consider that the
Subversion project itself has always had a notion of who is allowed
to commit where, but it's always been enforced socially. This is a
good model of community trust, especially for open source projects.
Of course, sometimes there are truly legitimate needs for
path-based access control; within corporations, for example,
certain types of data really can be sensitive, and access needs to
be genuinely restricted to small groups of people.
More Detail can be found
HERE
