Frequently Asked Questions
Repository Hosting is a hosting service for software project management tools. We specialize in hosted Trac, Subversion, Git, and Mercurial.
However, unlike our competitors, we strive to make hosted project management simple again. There is only One Plan and One Price. $6.00 per month buys you unlimited repositories, users and Trac instances — AND 2GB of storage.
We are proud to say that all of our servers are currently hosted with Amazon EC2 in their US East datacenter in Virginia. Amazon EC2 enables us with an unprecedented reliability, redundancy and scalability. Leveraging the entire Amazon infrastructure, Repository Hosting can react very quickly to our customers growing needs.
As developers, we understand what it means to entrust your code to someone and we take this responsibility very seriously.
Regarding security, every Repository Hosting account has 128-bit SSL encryption enabled by default. All repositories can also be accessed over SSL or SSH.
Regarding backups, a snapshot of all account data is taken hourly and stored in multiple physical locations. Additionally, customers can download project backups at any time, including the entire Trac project and associated repository dump.
We stand ready to help you with any questions you may have. Please email us at email@example.com.
Repository Hosting currently supports English, Simplified Chinese, and Russian. Our Account Dashboard, settings pages, help pages, Trac, and FAQ are all available in these languages. However, currently GitWeb, hgweb, and the interfaces for some optional Trac plugins are only available in English. Also, we can only provide support in English at this time.
In addition, the Trac interface is available in 33 languages.
We currently accept VISA, MasterCard, American Express, Discover, PayPal, and Skrill.
Every account includes 2GB of space — more than enough for most teams. However, if you require more storage, we charge $1.00 for each additional gigabyte.
For instance, if you are using 3.5GB of disk space, you will be charged your standard amount ($6.00) plus $1 for each of the 2 additional gigabytes of storage required — a total of $8.00 ($6.00 + $2.00).
Your first 30 days are completely free. After your 30 day free trial has ended, we will bill your credit card or PayPal account as provided upon sign up.
For simplicity, we bill our customers with recurring monthly payments. However, there are times when it is more convenient to make a one-time payment. For example, you might want to pay at a different interval, such as quarterly or annually. Or you might be having trouble getting your credit card accepted, as certain financial institutions don't allow their cards to be used for online recurring payments.
To accomodate these cases, we provide the option to prepay for your account for any number of months. During this time your regular monthly payments will be suspended. After your prepaid term has expired, you can either choose to prepay again, or your monthly payments will automatically resume.
You can make a one-time payment from the Billing tab of your Account Settings page.
Each Repository Hosting account is represented by a unique subdomain (i.e. mysubdomain.repositoryhosting.com) and has its own set of unique users. To login to your account, you must first visit your account's subdomain directly.
If you do not remember your account subdomain, please note that it was in the welcome email sent to you upon signup.
If you have lost your password, simply visit your account and click the "Sign In" link. Then, click the "Password Reminder" link at the bottom of the sign in box.
If you do not see this link, be sure that you are not attempting to sign in from within a Trac project.
Many of our customers use continuous integration software or other software that automatically connects to their repositories on a regular basis to look for changes. These programs are very useful, and we support their use with Repository Hosting. However, sometimes a customer will inadvertently set a very short polling interval, and this will result in tens of thousands of requests to our servers. Out of fairness to our other customers, who experience slower performance as a result, we have had to implement the following QoS policy. Our goal is not to restrict our customers in any way besides discouraging short polling intervals on automated software.
The following limits only apply to Trac, repository, and shared drive requests. Access to the Account Dashboard is unrestricted.
For Subversion and Webdav HTTP(S) connections, all accounts will be limited to 15 requests-per-minute (rpm), but allowed to "burst" up to 30,000 requests. In other words, when your rpm is greater than 15, requests are slowly "borrowed" from your bucket of 30,000 requests. When your rpm is less than 15, the requests are returned to the bucket. If your bucket of requests ever gets empty, any further requests will be "slowed down" to 15 rpm. If you then continue to try to make requests faster than 15 rpm from multiple connections after your bucket is empty, you will eventually start seeing HTTP 503 errors being returned. The solution is just to stop making requests for a short time so that your bucket of requests has a little time to refill.
The above policy really only kicks in if you have automated tools polling our servers at a rate higher than 15 rpm indefinitely. We suggest that you keep those requests to 10 rpm or less. Also please note that Subversion often uses multiple requests to perform one action, so you should assume that each time your software polls the repository, it results in 10-20 requests. A simple rule of thumb would be to set your polling interval to every x minutes where x is the number of repositories you are polling.
Git and Mercurial connections over HTTP(S) are significantly more efficient and therefore result in far fewer, but more costly, requests. As a result, Mercurial will be limited to 7 rpm and allowed to burst up to 15,000 requests, and Git will be limited to 3 rpm and allowed to burst up to 4,000 requests.
For SSH connections to your repositories, each account is allowed 2000 requests in a 24-hour period. If this limit is exceeded, then further connections will be limited to 3 every 2 minutes until your 24-hour rate falls below 2000 again.
We have created an API endpoint that lets you check your request count for the last 24 hours, so that you can monitor your usage. You may access it by going to
We will be monitoring the effects of this policy and tweaking it where needed. If you have any questions or concerns about this policy, please don't hesitate to contact us.
If you would like to cancel your account, simply go to your Account Settings page, and there will be a "Cancel Account" link at the top-right corner of the page. Note that only Account Administrators may cancel the account.
Repository Hosting gives you a significant amount of control over user permissions. You may add many users to your account, and place them into groups. You may also create many projects and place them into categories. Permissions can then be set on users and projects, and even on groups and categories. For example, you can set a permission that says "Give all users in the Software Engineers group read and write permission to the repositories of all projects in the Consulting Work category."
You may specify None, Read, or Write access to repositories and shared drives. You may then specify fine-grained Trac permissions from Trac itself (e.g. WIKI_VIEW, TICKET_CREATE, TRAC_ADMIN). Additionally, you may make someone an Account Administrator, which gives them full control over all aspects of the account, such as billing and the ability to create users and groups. You can also make someone a Project Administrator for a specific project. This would give them full access to the project, including the ability to modify project settings.
You may also give certain permissions to the general public. This is handy if you have an open-source project or want anonymous users to be able to create tickets. From the Project Settings page you can give Read access to the repository for anonymous users. From Trac, you may specify permissions that should be given to anonymous users by setting the permissions on a user named "anonymous".
This custom callbacks sends a simple HTTP GET request to the URL you specify. You may also set a username and password to use for basic authentication. The variables $REV, $PROJ, and $BRANCH may be used in the URL and will be replaced by the revision or commit id, the project abbreviation, and the name of the branch (Git and Hg only), respectively. For example:
This custom callback sends an HTTP POST request to the URL of your choice, optionally passing the username and password for basic authentication. The data is sent as XML and contains the revision, author, created at date, log message, and branch name (Git and Hg only) of the commit, along with the name of project. For example:
POST http://bob:firstname.lastname@example.org/notifications <?xml version="1.0" encoding="UTF-8"?> <commit> <revision>0cea058405ad688bf4d6486d090e0e70f9111545</revision> <author>Bob Smith (email@example.com)</author> <created_at>2011-12-03T12:53:53+00:00</created_at> <log>Added a new module to the project.</log> <branch>master</branch> <project>myproject</project> </commit>
Types of Notifications
Each user in an account may specify the email notifications they receive. Email notifications are provided for:
- Repository Commits: Every time a commit is made to the project's repository. The notification will contain a summary of what changed.
- Ticket Changes: Every time a ticket is created or modified. The notification includes a summary of what changed.
- Wiki Changes: Every time a wiki page is created or changed.
- Backup Completions: Every time an automated backup has been completed. You may then choose to download the backup.
- Invoices: For account administrators, a copy of the monthly invoice is sent each time the account is billed.
You may choose which tickets you would like to receive notifications for. The options are:
You may also specify specific wiki pages and tickets that you would like to receive notifications for, regardless of your notification settings. To do this, simply click the "Watch This" link in the top-right corner of the screen when you are viewing a ticket or wiki page. To stop watching an item, simply click the "Unwatch This" link.
Repository Hosting uses public key cryptography to authenticate all private access to repositories over SSH. In order to access a private repository, or commit to a public repository, you will need to generate an SSH keypair and provide Repository Hosting with the public half of the keypair.
NOTE: If you have multiple accounts at Repository Hosting, then you will need to generate a new keypair for every account.
To register your public key, first log into Repository Hosting and then click the "My Profile" link in the upper right hand corner, or on the Settings link next to a user on the Account Dashboard. Select the "Public Keys" tab and then paste the entire contents of the public key file (with the .pub extension) into the form for adding public keys.
For more details on how to generate a keypair, see this page.
Using SSH to access repositories from Windows is less straightforward than on Mac or Linux as Windows does not come with an SSH client. We suggest using either the PuTTY or OpenSSH third-party clients. We have found a couple of good tutorials that will help.
- Git via SSH on Windows
- Mercurial via SSH on Windows (additional tutorial)
- Subversion via SSH on Windows
plink -agent subdomain.repositoryhosting.com
Enter "svn", "git" or "hg" (depending on your repository type) when prompted for a username. Then press "y" when prompted to cache the server's key. If you have trouble using PuTTY, as some of our customers have, you will want to try using OpenSSH instead.
Because you need to use separate SSH keys for each of your Repository Hosting accounts, you need a way to switch between the keys on your client. The easiest way is to modify the ssh_config file (on Ubuntu, this is located here: /etc/ssh/ssh_config). Use the following sample setup as a guide:
# personal account Host personal.repositoryhosting.com IdentitiesOnly yes IdentityFile ~/.ssh/personal_key # corporate account Host corporate.repositoryhosting.com IdentitiesOnly yes IdentityFile ~/.ssh/corporate_key
There are two common situations where you may have trouble connecting to your repository via SSH. First, there is a brief delay between creating a new project or updating permissions and being able to access the repository via SSH. This delay is generally less than one minute, but in rare instances it may take a little longer. If you try again after a few minutes you may be able to connect.
A second reason you may be unable to connect is if you are using the same SSH key in another Repository Hosting account. We do not support this scenario, and you will need to generate a different key for each account. Please see the FAQ entry on managing multiple keypairs for more information.
If you are still having trouble, please contact us at firstname.lastname@example.org for more information. Please let us know the exact error message you are receiving, along with the outputs of the following two commands, which will allow us to debug the problem:
ssh-add -l ssh -vvv [vcs]@[subdomain].repositoryhosting.com
Replace [vcs] with the repository type you are connecting to (svn, git, or hg) and replace [subdomain] with your account subdomain. For example:
ssh -vvv email@example.com
Sometimes you might find yourself behind a firewall that blocks port 22, which is the standard SSH port. This normally would keep you from being able to connect to your repositories over SSH. There are two ways around this. First, you could connect via the HTTPS repository URLs instead. Almost every firewall lets HTTPS (port 443) through.
However, we have also opened up the nonstandard port 223 for SSH access. To connect using it, simply add the port to your repository URL, as follows:
- Subversion: svn+ssh://firstname.lastname@example.org:223/accountname/projectname
- Git: ssh://email@example.com:223/accountname/projectname.git
- Mercurial: ssh://firstname.lastname@example.org:223/accountname/projectname
Repository Hosting creates hourly backups for our own disaster recovery plans. If something were to happen to our system as a whole, then we would restore it from the last available backup, which would be no more than one hour old. We keep these backups with decreasing resolution over time, for more than a month.
It should not be necessary to keep your own backups at all. However, we do provide a scheduled backup facility for your peace of mind should you wish to do so. You can even have your backups automatically copied to an Amazon S3 account of your choosing. Scheduled backups are free, of course.
To export the data for a project, simply request a backup of it. The backup contains everything you would need to recreate your project somewhere else, including a dump of the repository with the full history, the Trac data, plus a copy of the contents of the shared drive.
To request a backup, go to the Project Settings page, click on the Backups tab, and then click on the "Request a backup of this project right now" link. We will generate the backup for you and then notify you via email when it is complete. You can either download it from our site, or specify an S3 bucket you would like it sent to.
The backup file is compressed as a .tar.gz file. Within it, the /trac directory contains the results of a "trac-admin hotcopy". The /webdav directory contains a copy of all the files on the shared drive. Finally, there is a dump file of your Git, Mercurial, or Subversion repository, created with "git fast-export --all", "hg bundle -a" or "svnadmin dump", respectively.
You may recreate your repository using the following commands:
# git repository git init cat git.fast-export.gz | gzip -d | git fast-import git reset --hard # mercurial repository hg init hg unbundle hg.bundle hg update # subversion repository svnadmin create repo svnadmin load repo/ < subversion.dump
Note for projects that are greater than 5GB:
Dumps of large repositories can take a very long time for us to generate. As a result, we bundle the repositories of these large projects in their original binary form, rather than as a dump file. Dump files are portable, but the binary version must be used with specific platforms and client versions.
We have created a simple method for you to extract a portable dump file from the binary version, using Docker. The backup will contain a Dockerfile, with instructions of how to use it as comments at the top of the file.
Of course, if you have any questions about how to do this, please contact us at email@example.com.
Backups are available to be downloaded from our site for 4 days, or until the sum of the backups for your account reach 10GB, whichever comes first. Backups uploaded to an Amazon S3 account are accumulated and never deleted.
The best way to do this is to turn on the S3 upload feature. That way the backup is sent to an S3 account that you own every time. If you wanted the backups on your local server as well, you could run s3sync on it daily to sync up with the S3 account.
Another way to do this is to create a script that automatically downloads the backup each day. Backups may be accessed using a URL such as:
The URL contains the year, the month, the day, and then a 2-digit index. The index is 00 for the first backup created in a day, 01 for the second, etc. If you just have daily backups set up, then you will only have one backup in a day, and the index will always be 00.
We also provide a handy URL for retrieving the most recent backup for a project:
This allows you to create a simple script to download the backup each day. For example, on Linux you could use something like the following to download today's backup (the first command logs you in, the second downloads today's backup):
curl -sS -X POST 'https://sub.repositoryhosting.com/session' -d "username=myuser&password=mypass" -c cookies.txt curl -sS -L "https://sub.repositoryhosting.com/projects/1/backups/latest" -b cookies.txt -o "subdomain.`date +%Y-%m-%d`.tar.gz"
One of our customers has created a more customizable download script, which you can find on his blog here: http://samsalisbury.net/articles/repositoryhosting-backup-script/. Thank you Sam!
Amazon S3 supports the ability to specify object expiration through Object Lifecycle Management. For instance, you could set your backups to be automatically deleted after 30 days, or archived to Amazon Glacier.
Trac is an enhanced wiki and issue tracking system for software development projects. Trac uses a minimalistic approach to web-based software project management. Our mission is to help developers write great software while staying out of the way. Trac should impose as little as possible on a team's established development process and policies (from the Trac website).
For more information about Trac, please see: http://trac.edgewall.org.
Repository Hosting servers are currently running Trac 0.12.3.
Trac Plugin Versions:
- Agilo: 0.9.6.2
- Batch Modify: 0.8.0
- Blog: 0.1.1
- Custom Notifications: 0.12.1
- Custom Roadmap: 0.4
- Custom Field Admin: 0.2.5
- Discussion Forum: 0.8
- Download Releases: 0.3
- Markdown: 0.11.1
- Roadmap Hours: 0.5
- Trac Captcha: 0.2.2
- Table of Contents: 220.127.116.11
- Tags: 0.6
- Ticket Import: 0.8
- Timing and Estimation: 1.0.7b
- Wiki Backlinks: 1.0
- Workflow Editor: 1.0.2
- Worklog: 0.2
- Wysiwyg Editor: 0.12.0.3
- XMLRPC: 1.1.2
When you first create a Git or Mercurial project, there is no source to browse. Once you have committed at least one revision to your repository, you will then be able to browse the source from within your Trac project.
We support the following plugins:
- Batch Modify
- Custom Roadmap
- Custom Ticket Fields
- Discussion Forum
- Download Releases
- Roadmap Hours
- Trac Captcha
- Table of Contents
- Ticket Import
- Timing and Estimation
- Wiki Backlinks
- Workflow Editor
- Wysiwyg Editor
We also support the following additional features:
- Email into Trac
- Commit notification sent to Twitter, Campfire, Basecamp, CIA, or a custom callback
- XML-RPC API (enables Eclipse Mylyn Integration)
- HTML Email Notifications of Tickets, Wiki Pages, Blog Posts, and Forum Messages
If a project is setup to process commit messages, the following commands entered into your commit log message have the potential to affect ticket status:
close, closed, closes, fix, fixed, fixes The specified issue numbers are closed with the contents of this commit message being added to it. references, refs, addresses, re, see The specified issue numbers are left in their current status, but the contents of this commit message are added to their notes.
When processing the log message, commit messages are searched for text in the following form:
command #1 command #1, #2 command #1 & #2 command #1 and #2
Instead of the short-hand syntax "#1", "ticket:1" can be used as well. For example:
command ticket:1 command ticket:1, ticket:2 command ticket:1 & ticket:2 command ticket:1 and ticket:2
In addition, the ':' character can be omitted and issue or bug can be used instead of ticket.
You can also have more than one command in a message. A fairly complicated example of what you can do is with a commit message of:
Changed blah and foo to do this or that. Fixes #10 and #12, and refs #12.
This will close #10 and #12, and add a note to #12.
Timing and Estimation Plugin
If you have the Timing and Estimation Plugin enabled, then there is support for specifying time spent in commit messages. The time specified will be automatically added to the spent time field for the ticket.
Blah refs #12 (spent 1.5) Blah refs ticket:12 (sp 1) Blah fixes #12 (2.5)
As above it is possible to use complicated messages:
Changed blah and foo. Fixes #10 (1) and #12 (2), and refs #13 (0.5).
This will close #10 and #12, and add a note to #13; and also add 1h spent time to #10, add 2h spent time to #12, and add 30m spent time to #13.
Finally, if you have the Agilo Plugin enabled, then there is support for specifying the remaining time for a ticket in the commit message.
Blah remaining #12:2h Blah still ticket:12:1h Blah fixes #12, time #13:4h
We do support importing existing Trac projects. The Trac project must be using a Sqlite3 database, and we recommend that it be the same version of Trac as the one we are running (currently 0.12.3). You may upload a compressed copy of your Trac project by going to the Project Settings page for your project, selecting the Trac tab, and then clicking on "Import a Trac Project". Please note that we import the Trac database (tickets, wiki pages, permissions, etc.) and attachments, but not the config file, custom templates, or plugins.
Subversion is an open source version control system designed as successor to the once popular CVS. It is widely accepted by both the open source community as practically the de facto standard in version control systems. It is also used broadly in the corporate context.
Subversion offers a variety of features, including:
- directories, renames, and file meta-data are versioned
- atomic commits
- branching and tagging
- versioning of symbolic links
- space efficient binary diffing
- client availability on a multitude of platforms
For more information about Subversion, please see: http://subversion.tigris.org.
Repository Hosting servers are currently running Subversion 1.8.10.
You may access your Subversion repositories using either the HTTP (http:// or https://) or SSH (svn+ssh://) protocols. To use SSH, you will first need to register your SSH key on the My Profile page. You may also view your repositories directly from your browser, either by viewing them in Trac from the Browse Source tab, or by browsing to the HTTP repository URL, which provides a simple file view of the repository.
We would be glad to import a repository dump file for you. We will require the dump file for your repository (as created with 'svnadmin dump'). This dump file can be easily sent to us by clicking the 'Upload a dump file' link available from the Settings page on any given project. Once we receive the dump file, we will automatically load it up and send you an email as soon as it has been completed.
Git is an open source, distributed version control system designed to handle everything from small to very large projects with speed and efficiency.
Every Git clone is a full-fledged repository with complete history and full revision tracking capabilities, not dependent on network access or a central server. Branching and merging are fast and easy to do. (from the Git website)
For more information about Git, please see: http://git-scm.com.
Repository Hosting servers are currently running Git 1.8.4.
You may access your Git repositories using either the Git (git://), HTTP (http:// or https://), or SSH (ssh://) protocols. To use SSH, you will first need to register your SSH key on the My Profile page. You may also view your repositories directly from your browser, either by viewing them in Trac from the Browse Source tab, or by accessing them in "GitWeb", which is available at the HTTP repository URL.
Mercurial (abbreviated Hg) is an open source, distributed version control system.
Mercurial is dedicated to speed and efficiency with a sane user interface. Mercurial offers you the power and speed to efficiently handle projects of any size and kind. Every clone contains the whole project history, so committing, branching, tagging and merging are local operations which makes them fast and convenient. You can use a multitude of workflows and easily enhance its functionality with extensions. (from the Mercurial website)
For more information about Mercurial, please see: http://mercurial.selenic.com/.
Repository Hosting servers are currently running Mercurial 2.7.
You may access your Mercurial repositories using either the HTTP (http:// or https://) or SSH (ssh://) protocols. To use SSH, you will first need to register your SSH key on the My Profile page. You may also view your repositories directly from your browser, either by viewing them in Trac from the Browse Source tab, or by accessing them in "hgweb", which is available at the HTTP repository URL.
Windows support for WebDAV is difficult at best. For your own sanity, we would suggest trying a third-party WebDAV client such as WebDrive or NetDrive. For more information, see: http://www.webdrive.com/products/webdrive/winindex.html and http://www.netdrive.net/home.html
You can connect to your Repository Hosting shared drive from a Mac using Finder.
Go to "Go" -> "Connect to Server". Enter the address of your shared drive, e.g.: https://[subdomain].repositoryhosting.com/webdav/[subdomain]_[project abbreviation]
If you are running a Linux distribution that uses Nautilus, you would normally connect to your share drive by going to "File" -> "Connect to Server" and select "Secure WebDAV (HTTPS)". However, we have found that this often does not work. In this case, you may use the following as a workaround.
- Open Nautilus
- Make sure your location bar is visible (can be enabled via the menu: "View" -> "Location bar")
- Make sure the location bar is in text mode (you can toggle between text and button mode via the first button in your location bar)
- Enter the full URL for your Shared Project Drive into the location field but change https into davs. E.g.: davs://[subdomain].repositoryhosting.com/webdav/[subdomain]_[project abbreviation]
- Enter your username and password when asked (the same as is required to log into the web interface).
If you have any questions about our service, please do not hesitate to contact us. You can start by either filling out the form to the left, or emailing us at firstname.lastname@example.org.
Worst Case Scenario
Despite best efforts, even the most hardened of sites can go down. If we are ever experiencing any technical difficulties with our infrastructure, we will use an independently hosted Status Page to keep you informed.
If you suspect that something may be wrong with Repository Hosting, please be sure to visit: