For teams working in a single location, the repository should probably be located on a server on the local network. For many organizations, network security may not be an issue, in which case the SVN network protocol (svn://) will provide the best performance. If network security is an issue then the svn+ssh:// or https:// protocols may be a better choice.
If members of your project (such as external contractors) work off-site then you will probably need to serve your repository using HTTP with Apache. Whether you use http:// or https:// will depend on the sensitivity of your project’s code. If you are working on an open source project then http:// may be sufficient (although many open source projects in fact use https:// for non-anonymous access). If you are working on a commercial software project then https:// will probably be a requirement.
Small organizations may find hosting an attractive alternative. Numerous providers (such as Beanstalk) provide inexpensive hosting plans to organizations which may meet your needs. Hosting may be of particular interest to small, loosely-knit organizations (such as start-ups) which do not have or can’t afford a shared IT infrastructure.
It may be useful to define the roles played by the members of your team. You can use these roles to define authorization policies for your repository. Candidate roles may include:
Has read/write access to the entire repository including the tags and branches folders. Is responsible for creating tags and branches.
Has read and write access to the project’s trunk folder and read access to everything else. Most development staff will be granted this role.
Members of non-development parts of the organization (such as marketing, support and testing) may require read-only access to areas of the repository. Such users may even be able to access the repository anonymously, depending on the security policies in place. In larger organizations, other organizational units which consume your organization’s output may need read-only access to your repository (for example when referencing your code via external reference).
While it may seem counter-intuitive to pull changes before pushing them upstream with a commit, this workflow helps minimize conflicts and decrease merge effort.
Larger development organizations may profit from working on various aspects of the project in parallel. This can be achieved by developing on multiple branches.
The exact designation of these branches will differ from project to project. Some organizations will encourage committers to work on developer-specific branches in parallel while others will prefer branches organized along functional, technical, geographical or organizational boundaries.
While branch-based development affords a team’s members a high degree of independence, it comes at a cost of increased integration effort in the form of inter-branch merging. At designated integration points during the project, team-members will be required to merge their changes upstream from their working branch up to the integration (or build) branch.
Branched-based development can significantly increase the complexity of a project’s version control and should not be attempted without good reason. In particular, infrequent integration can cause significant interruption to a project’s progress.