A Repository Trigger is used to trigger a Configuration when a change is committed to the repository you specify in the trigger.
Setting up a trigger for a non distributed version control system will give you the following options:
The only additional parameter you get is the Quiet Period. When a change set is detected on a repository you set the trigger up to monitor, a build is created and put in the Build Queued state. It sits in the queued state until the quiet period expires. While in the quiet period, additional commits to the repository won't trigger new builds but instead append those change sets to the build that's in the quiet period.
The options for a Repository Trigger differ slightly depending on the type of repository you select from the drop down. If it's a distributed version control system (DVCS), you will get additional options like which branch to trigger from. As an example, you could setup a Repository to monitor all branches then create a different repository trigger for each type of branch... dev branch, release branch and/or feature branches.
The three types of branch monitoring options are:
When this option is selected, the trigger will start a build if any changes are made to any branch. You also get the option to only send notifications to users who triggered the build.
When this option is selected, the trigger will start a build if a change was made to the repositories' default branch. The default branch is specified when you create a repository which is a DVCS.
When this option is selected, the trigger will start a build when a change is made to a branch whose name matches the regular expression you supply. You also get the option to only send notifications to users who triggered the build.
The regular expression entered in the screen shot above is ^f-.*. This will match any branch in my repository that starts with f-.