SVN hosting & Git hosting in Germany

You create a local copy with a checkout, which downloads the current state of the repository to your computer. On Windows, TortoiseSVN is popular because it integrates into Explorer and works via right-click. Alternatively, you use the command line or a client in your development environment. After that, you work locally and regularly run an update to fetch your team's changes. Subversion then merges the changed lines without overwriting your own work.

You create users and groups in our SVNDevAdmin management interface. To do so, log in and select “Users” on the left. Then enter the name, username, email address and password, and decide whether the account is active; deactivated users have no access. Finally, you grant permissions: either globally for all repositories or specifically in the access rights of a single repository. You can try this out in our SVN hosting trial.

You make your changes available with a commit, which transfers the state of your local working copy to the central repository. Your colleagues then pull the changes into their own working copies with an update, without losing their work. To keep the team informed, you can also add a post-commit hook script that, for example, sends an email listing the changed files after every commit. Custom hook scripts are included in our SVN plans.

You resolve a conflict by cleaning up the affected file by hand and then marking it as resolved. A conflict occurs when you and a colleague have changed the same lines of a file, so Subversion cannot merge the changes automatically during the update. Many clients such as TortoiseSVN therefore show both versions side by side, and you decide line by line. Only then can you commit again. This way, only reviewed code reaches the repository.

In web development, SVN hosting replaces error-prone uploads via FTP. When several developers or computers work on the same project, one of them otherwise quickly overwrites someone else's changes. With a repository, however, all changes end up in one place and Subversion merges them. In addition, a hook script can send a notification email after every commit or automatically transfer changed files to the web server. With ReposDev, repositories and web space even come in the same plan.

Yes, Subversion is a centralised version control system. All developers work with the same repository on the server and download local working copies from it. Unlike Git, however, a working copy contains only one state rather than the full history. The server is therefore the central collection point: if it fails, nobody can check changes in or out. That is why we run our hosting servers as a cluster and back up your repositories daily in German data centres.

To move a repository with its complete history, create a dump at your current provider with “svnadmin dump”. It contains all revisions, log messages and metadata. On the new server, it is then loaded with “svnadmin load”. If the old provider offers neither SSH nor a dump export, mirror the repository with svnsync instead. Afterwards, your developers switch their working copies to the new address with “svn relocate”. If you move to us, you can load the dump yourself, or we do it for you.

You store your source code in a repository with us and give your team access. Each developer then works in their local working copy and commits changes to the central repository without getting in anyone's way. We take care of server operation, updates and security, and we also back up your repositories daily. For tickets and project planning, you can add Redmine as well. This central location pays off especially when several developers are involved.

Tools that connect directly to the repository are a good fit, such as Redmine, Jira or Mantis. Customers and team members record bugs and requests as tickets, and developers link their commits to the matching ticket. This way, everyone can see which change solves which problem. Redmine connects directly to SVN and Git; you can add it as an option or use it as Redmine hosting. We also install Jira, Redmine and other applications on your REPOS server by arrangement.

You usually access a Subversion server via HTTPS: the Apache web server provides the repositories via WebDAV, and all common clients support this method. Alternatively, there is SSH, which also encrypts the connection, and Subversion's own svnserve protocol, which transmits unencrypted by default. With us, connections to your SVN repositories are SSL-encrypted. You reach Git repositories via HTTPS or via SSH with a key. In your browser, you can also view files and versions with WebSVN and GITWeb.

You use a post-commit hook script for this. Subversion runs it after every successful commit, and the script then sends an email to your team, for example with the log message, changed files and diff. Common tools for this are mailer.py from the Subversion project or SVN::Notify. This keeps everyone informed, and each developer quickly sees whether a change affects their work. You can add custom hook scripts in all our SVN plans.

The simplest way is a post-commit hook, which transfers changed files to the web server automatically after every commit. Manual uploads via FTP are no longer needed, so your team can no longer forget a file. In addition, the website always matches the state of the repository. With our ReposDev plans, repository and web space come in the same plan, so you develop, test and publish without switching environments. You can also access the web space directly via SSH.

Yes, teams in particular benefit from SVN hosting. Everyone works in their own working copy, and the central repository merges all changes. Because the whole team depends on the server, stability and data security matter most: our hosting servers run as a cluster, and we back up your repositories daily. Developers and repositories are also unlimited in every plan, so your team can grow at no extra cost. For tickets and project progress, you can add Redmine as well.

Yes, version control pays off even when you work alone. You can trace every change, restore earlier states and archive delivered versions with tags. You can also work on the same project from several computers, such as an office PC and a laptop. Your own server is rarely worth it for this, because setup, updates and backups take time. With our ReposOnly plan, we handle all of that for you. Try it free for one month.

That depends on how much your team relies on the repository. If the server fails, everyone can keep working locally, but nobody can check in or fetch changes. For most teams, stable hosting is therefore enough: our hosting servers run as a cluster, so a second machine takes over if one fails. If you need more, we run your REPOS server with high availability on our VEP Cloud. We are happy to advise you on the right solution for your requirements.

Bugzilla is a bug tracker: it manages bug reports and change requests, while Subversion versions the source code. If you link the two, you can see for every bug which revision fixed it. As a result, you can still quickly find out later when a problem was introduced. Bugzilla is free software, is based on Perl and needs a database. As an alternative with a wiki, time tracking and direct SVN and Git integration, we offer Redmine; we install Bugzilla on your REPOS server by arrangement.

You connect Subversion and Bugzilla with a hook script or an integration tool such as Scmbug. The script reads the bug number from the commit message and records the revision in the matching Bugzilla entry. If both systems run on the same server, a few lines of Perl are often enough. You should also require every commit to include a bug number. This way, you can always trace who changed what and when. We set up the integration on your REPOS server by arrangement.

That depends on how much you need. Bugzilla focuses on bugs and change requests and is simple and proven for that purpose. Trac, on the other hand, also offers a wiki, a roadmap and a repository browser, so it suits teams that maintain documentation together. A third option is Redmine: it combines tickets, a wiki, time tracking and multiple projects and connects directly to SVN and Git. You can add Redmine as an option with us.

Yes, Jira can be connected to Subversion, for example with apps from the Atlassian Marketplace. Jira then shows the related commits for each issue, provided your developers include the issue key in the commit message. TortoiseSVN also supports this by asking for the issue key in the commit dialog. Setting it up is therefore mainly a matter of configuration. We can also install Jira itself on your REPOS server by arrangement, so repositories and tickets run on one server.

You need your own server when a plan reaches its limits, for example with very large repositories, many simultaneous users or special requirements for configuration and security. A REPOS server then gives you guaranteed resources, Plesk and SSH access, while we handle installation, updates and backups. If your needs keep growing, you move to a larger plan. On our VEP Cloud, you can also adjust resources flexibly. If checkouts and commits become noticeably slower, it is best to get in touch with us.

It is not mandatory, but it is strongly recommended. Without encryption, third parties can read passwords and source code. Encryption also protects against man-in-the-middle attacks, in which an unknown computer secretly places itself between client and server. With SSL/TLS or SSH, however, client and server verify that they are really talking to each other. That is why connections to our SVN hosting are SSL-encrypted, so you do not need to set anything up yourself.

No. With our SVN hosting, access is already SSL-encrypted, so you do not need your own certificate. If you want to reach your repositories under your own domain, we connect the domain including a free SSL certificate. If you run your own server, a self-signed certificate is technically sufficient. However, clients then show a warning on first access, and you have to verify the fingerprint yourself.

You load a dump from “svnadmin dump” into an empty repository with “svnadmin load”; you can do this yourself, or we do it for you. Note that a dump contains neither hook scripts nor users and access rights. You set these up again in SVNDevAdmin afterwards. If web space and databases are part of it, upload the files via FTP and import the database dumps. If, on the other hand, you need an earlier state from our daily backup, we restore it free of charge on request.

With the “svn blame” command (in TortoiseSVN, “Blame” in the context menu), you can see for every line of a file who changed it and in which revision. In addition, “svn log” shows all commits with author, date and message. This requires every developer to work with their own user account, which you create in SVNDevAdmin. If a change is wrong, you can then revert it with “svn merge” without losing the history. If such cases occur often, better coordination within the team also pays off.

Yes, the structure pays off from the very beginning. The trunk holds the main line of development, branches let you work on features or fixes separately, and tags record released versions. Switching to this structure later, by contrast, takes a lot of effort. A proven approach, for example, is to keep the trunk always working and commit unfinished work to branches, so interim states are not lost either. The free online book “Version Control with Subversion” (svnbook.red-bean.com) explains more.

It is better to commit often, in small, self-contained steps. Small change sets keep the history easy to follow, and errors are easier to find and undo. Too many tiny commits, however, clutter the history, so agree on a common approach within your team. Tags, on the other hand, mark milestones, typically every release. This way, you know later exactly that version 2.1, for example, corresponds to a specific revision, and you can reproduce bugs precisely.

Delete the files with “svn delete” (in TortoiseSVN via the context menu) and transfer this with a commit. From that revision on, they are no longer in the repository, but earlier revisions keep them. If you only delete the files in the file system, however, the next update brings them back. To keep the local file, use the “--keep-local” option. If confidential data such as passwords has ended up in the repository, change it immediately, because it remains visible in the history.

Subversion hosting makes your repository accessible from anywhere, so your team can work on the same code together. Each developer commits their changes to the server and fetches everyone else's changes with an update. You do not have to worry about the server, updates or daily backups. Unlike Git, which as a distributed system also stores the full history locally, the SVN server is the central point. With us, by the way, you manage SVN and Git together in one plan.

SVN (Subversion) is a free, centralised version control system. It stores every change to your files, so you can return to an earlier state at any time and trace who changed what. Developers mostly use it to version source code, but some also use it for documents, graphics or other binary files. With SVN hosting, you can also reach the repository from anywhere. This makes SVN a good fit for teams across several locations as well.

You create a working copy with a checkout. In TortoiseSVN, right-click a folder in Explorer, choose “SVN Checkout” and enter the address of your repository and your login details. On the command line, the command is “svn checkout https://servername/repository”. After that, you work locally and transfer your changes with a commit. With an update, you can fetch your team's changes at any time.

Yes. We connect any domain of your choice to your SVN plan, so you can reach your repositories under your own address, for example svn.your-company.com. A free SSL certificate for the domain provides the encrypted connection and protects your data. Just get in touch; we are happy to advise you and take care of the setup.

Yes. You can test ReposOnly and ReposDev free of charge and without obligation for one month. The trial ends automatically, so there is nothing to cancel. If you book a plan afterwards, your data and login details are kept in full. This lets you check at your leisure whether SVNDevAdmin, WebSVN and the access options fit your workflows. Start the ReposOnly trial or the ReposDev trial.

Yes. You access your Git repositories via SSH with public/private key authentication or via HTTPS. SSH key access is particularly convenient for server synchronisation and automated deployments, because you do not have to store any passwords. You add your public key once; after that, clone, pull and push work without entering a password. Your SVN repositories remain accessible via HTTPS.