Recently, I had to migrate a very large VCS over to bitbucket. After a few months, BitBucket sent me an e-mail saying that our bandwidth on their VCS was rather substantial and we would have to find a way to cut it down. Although I do not have the bandwidth data to see exactly what's causing all the problems, I wouldn't be surprised if TeamCity's version of CI, polling, was the cause. Aside from the fact that "checking for changes" seems to take a significant portion of time for our builds, it seems like the best possible way to do CI would be to enable commit hooks on all of our repositories; which bitbucket lets us do.
Now, in the world of Jenkins, the only thing Jenkins needs to get from a post-commit hook is the repository URL. Jenkins then knows enough about its tasks that it can simply run the task associated with that VCS root. Unfortunately, in the world of TeamCity, VCS roots seem a little more disjointed from their associated tasks ("configurations") and I cannot seem to Google up anything that properly describes how TeamCity can receive a post-commit hook trigger with just the repository URL. It seems like I'd have to pull all build IDs from TeamCity and somehow inject that data on a per-repository host on BitBucket to actually do this.
Does anyone have any experience with this process? Is what I'm asking even possible? Is it as much of a pain as it seems to be? I would hope TeamCity has some way of dealing with this because if it turns out that polling is our primary cause of traffic with BitBucket, we may either have to change our VCS (please no) or stop using TeamCity (please please no.)