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. If you are working on a commercial project then https://
will probably be a requirement.
Most web development projects cascade their development process across development, staging and production servers. In such projects the development server may be a good candidate for repository server.
Smaller web consultancies 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 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 and design staff will be granted this role.
Members of non-development parts of the organization (such as marketing, testing) may require read-only access to areas of the repository. Some clients or customers may even be able to access the repository anonymously, depending on the security policies in place.
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.
Developers should not attempt to access the working copy on the staging server remotely from their development computers. Instead they should use a remote shell (e.g. using SSH) or establish a remote desktop connection (e.g. using VNC) to work on the staging server. The svn command-line tool can then be used to commit changes back to the repository if the server is not running macOS Server.
If larger modifications are required then they should be assigned to developers for implementation in their standard development environment.
rsync
(or similar tool) to synchronize the production server with the exported project.
It is very important that the release manager publish files exported from the repository rather than from a working copy. Working copies contain hidden .svn directories which contain duplicate copies of all files. These files do not need to be published to the production server and will have a negative impact on upload/synchronization times.
Furthermore, working copies may contain additional files which, for security reasons, should not be deployed into a production environment where they are at risk of exposure on a public network.