Using Using version control systems SVN
Only key based access is allowed to the svn server. Public keys must be uploaded using the user portal and can be managed there as well.
Windows: E.g. use PuTTYgen to create a private-public-key pair.
Creating and managing repositories
This can also be done using the user portal ( https://user.informatik.uni-wuerzburg.de/ ), remember the following points during repo creation:
- Repo creation can take up to 5 minutes.
- You will receive an email confirmation after the repo has been created. This is a completely automatic system, so please be patient. Each repository is automatically assigned to a unique group. During creation of the repo, only the user who created the repository belongs to this group. But each repo-owner has the option of adding/deleting other users to/from this group through the user portal. All users belonging to this group have the same access as the owner.
- Access restrictions are at repo-level only and will not be changed. This means path based authorization is not supported.
Comment regarding path based authorization for svn repositories (Quote from http://svnbook.red-bean.com/en/1.7/svn.serverconfig.pathbasedauthz.html)
“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.
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. “
- Linux: Subversion
- Windows/MAC: SmartSVN
- Windows: TortoiseSVN (E.g. use Pageant to provide your private key to TortoiseSVN. This can be automated.) File:TortoiseSVN-Manual.pdf