У менеджера проекта родилась идея: отмечать тегом каждый successful билд проекта. Он обнаружли галочку такую в Hudson-е. 

Проект хранится в SVN. Проект внутренний - внутренний релиз для корпорации раз в месяц. А контрольные билды из сорцов делаются четыре раза в день. 

Кто-нибудь объяснит мне, это что best practice такой есть что ли? Или просто менеджер проекта безумствует, и у него такая блажь поиметь в конце каждого release cycle 120 тегов в SVN - по 4 тега в день?

Уж как я не пытался отговорить его, объяснять безумность идеи. Ничего не помогает. Помогите подобрать аргументы. 

А зачем его отговаривать?
И кстати, как сам менеджер объясняет желание создавать тэги?
И почему вас так волнует идея большого числа тэгов?

На мой взгляд идея хороша. Имея тэги для каждой версии он может быть на 100% уверен в том, что любой из билдов может быть пересобран в любой момент. И наличие таких тэгов может в один прекрасный день выручить из попадания в очень глубокую ж...

В конце-концов для автоматически создаваемых тэгов можно сделать отдельную ветку в SVN, - так, чтобы они не путались с тэгами создаваемыми разработчиками.

а зачем нужно пересобирать в любой момент любой из билдов? какова ценность билда собранного две недели назад, если этот билд не был релизом и его вообще никто не видел и имел с ним дело, и в следующем билде был закоммичен еще дополнительный код, которого не было в предыдущем билде? от какой такой глубокой ж может спасти билд 3 месячной давности? если после этого била было еще 210 билдов плюс два релиза?

1. никак не объясняет. ему очень хочется ставить тег на каждый билд. причем чтобы это было автоматически в Hudson-e. это так красиво выглядит. 

2. меня смущает размножение бесполезных сущностей, и трата времени и сил разработчиков и машинных ресурсов на поддержание этого зоопарка тегов

webmascon, 
я на знаю ваши методологии и цели 
но смысл тэггирования нужно как-то определить для себя (семантика)
Нет никакой объективной причины удачно прошедшего билда не быть способным собраться повторно.
и встает вопрос семантики: что для вас тэг.
У нас напр. тэг ставится перед и после апгрейда системы.
до апгрейда обозначаем blablabla_pre_qa, а после удачного "боевого" тестирования - blablabla.
т.е. мы используем тэг как метку состояния "боевой" системы.
с целью быть способным вернуться именно на тот коммит, который был использован.

но у нас система не идет к пользователям домой, а в датацентр.

если бы у нас был продукт конечным пользователям, то думаю, что интерфейс был бы заморожен и можно было автоматизировать тесты.
т.е. если какой-то код попал бы в ветку пользователей, автоматичекий билдер бы его 1) протестил, 2) собрал,. 3) протестил собранное.
и вот после 3)-го удачного этапа имело бы смысл вешать метки, а потом даже включать их в в продукт.