Насчет нестабильного Trunk – это четко по SVNBook.

Насчет переноса по фиксам – хорошее замечание. Я тоже так привык работать, когда фикс сразу кладется в release branch и в trunk, вместо того, что накапливается много в release branch’е.

Насчет примера. Мы точно так же и работали. И кстати, та же самая ситуация с тем, что возникается путаница, что в одной ветке может получить и 5.0 и 5.1 и 5.2.
Но это в целом решается с помощью tag’ов. Хотя для средних компаний редко нужно выпускать фиксы а-ля 5.1.1, когда идет работа уже над 5.2 (все на ветке 5.0), так что просто кладут в конец 5.0 и оттуда выпускают.

Структура репозитория (по SVN Book):

Product1/
trunk/
branches/
branch1
...
tags/
tag1
...
Product2/
...


Каши с логами не будет если указывать URL к конкретному продукту и более того к конкретной ветке (или транку).

Trunk – это НЕстабильная ветка. В нем ведется разработка последней версии продукта, которая находится в Alpha или Beta стадии. Как только продукт достигает стадии RC, создается ветка соответсвующего релиза. В идеале в этой ветке ничего не делается и она нужна только для пост-релизного сопровождения данной версии (создание сервис-паков).

Существует еще один нюанс при создании ветки для версии продукта. Если необходимо вести разработку нескольких версий продукта одновременно (а это я настоятельно рекомендую всячески избегать), то ветку для версии можно создать на более ранних стадиях (Alpha или Beta). Но при этом всегда стоит помнить, что самая последняя версия остается в транке.

Любые изменения в версионных ветках ОБЯЗАТЕЛЬНО должны быть перенесены в транк (причем «один фикс – один мерж», а не пачкой раз в неделю или месяц или при стабилизации ветки). Изменения из веток для более ранних версий переносить в ветки для более поздних версий рекомендуется делать только по необходимости. Возможны ситуации, когда исходный код веток отличается радикально, тогда этот фикс выполняется заново, но уже базируясь на коде новой ветки. Иногда бывает, что некий дефект из ранней версии не применим к более поздней. Тогда ничего переносить не нужно.

Ответвления от версионных ветвей допускаются. И здесь работает тот же принцип что и с транком. В них можно вносить изменения. Они становится некими аккомулятивными ветками.

Пример:
Ведем разработку версии 5.0. Работаем в транке. Достигнута стадия RC – реализована вся функциональность для этой версии (это требование для завершения Alpha стадии) и исправлены все найденые дефекты (это требование для завершения Beta). В этот момент создается ветка v5.0. И в этот момент можно приступать к версии 6.0 в транке. Если вдруг необходим некий хот-фикс для 5.0 версии, то он выполняется в v5.0 ветке и переносится в транк. При этом новый 5.0 RC билд строится из v5.0 ветки. Если, через некоторое время, будет принято решения выпустить 5.1 сервис-пак для версии 5.0 (а на этот момент новых билдов 5.0 версии быть не может), то изменения вносятся в ветку v5.0 (плюс эти же изменения обязательно переносятся в транк) и когда 5.1 сервис-пак достигнет стадии RC – создается ветка v5.1 из ветки v5.0. Если вдруг потребуется хот-фикс для 5.1 версии, то как и прежде, эти изменения (в ветке v5.1) обязательно должны быть перенесены в транк и обязательно в ветку v5.0. К сожалению, здесь есть небольшая путаница, поскольку ветка v5.0 плавно превращается в ветку для версии 5.1 (хотя название ветки остается v5.0), а затем в ветку для версии 5.2. Возможно эту путаницу можно решить с помощью промежуточной ветки v5.x, но это уже по вашему желанию.