По поводу "каждому изменению в репозитарии соответствует свой тикет" - у нас вполне выдерживается такая методика.

1) Теоретически, при коммите может срабатывать hook, которые проверят наличие указанной баги в багтрекере и даже то, что handler-ом этой баги является тот самый разработчик, который commit-ит код. Сам такое писал, но реально использовать не пришлось - вполне помогает фраза "просто надо так делать".
2) Если коммит относится к нескольким связанным багам, то указываем их все. Соответственно в багтрекере для каждой из багов будет выведен список измененных файлов и список связаных багов.

Вообще связь commit-ов с багами - штука очень полезная, т.к. позволяет:
1) По строчке исходника получить номер ревизии (svn annotate), а по номеру ревизии - к какой баге это относится. Очень помогает при ответе на вопрос "кто и зачем это сделал".
2) Многие исправления разработчиков можно заворачивать назад вообще не тестируя, т.к. по diff-у видно что поменяли не все файлы, забыли перенести правки из trunk в branch и т.п.
3) Если в багтрекере можно учитывать время, то сразу понятно как соотносится время работы над задачей с объемом изменений.