Как поддержать исходные версии и древовидную структуру проекта в репозитории управления исходным кодом

Для команды 4-5 разработчиков, использующих Визуальный безопасный источник (VSS) 2005, что лучшая практика должна поддержать исходные версии?

Наше требование состоит в том, чтобы поддержать и определить версию, которая в настоящее время работает. Этот путь в любом случае, мы будем знать, какая часть кода была продвинута во время развертывания.
До сих пор это - то, что я имел в виду.

- соединительная линия - Основное решение и проект
- Ответвления Dev - ответвление, созданное для разработки и улучшений

-Dev (some enhancement)  

- Выпуск - выпускает ответвления

-Release 2.1.0  
-Release 2.1.1  
-Release 3.0

Все, что запускается с тире (-) выше, является папкой в репозитории.

Я думаю, что каждый раз мы должны сделать улучшение к нашему проекту, мы заставляем dev перейти от основной соединительной линии всего проекта. Это будет то, где разработчики продолжат работать. После того как разработка завершена, и UAT сделан, мы продолжаем двигаться к развертыванию.

После того, как проект (в этом случае веб-приложение) развертывается и подтвердил, что это стабильно, мы делаем Выпуск (версия #) ответвлением ответвления Dev выше. Позволяет говорят, что это - Выпуск 3.0, мы теперь знаем, что в развертывании июля 2010 продвинули код в папке Выпуска 3.0.

Мы затем объединяемся (это легкое в VSS2005), код Выпуска 3.0 с соединительной линией. Таким образом, соединительная линия всегда является последним развернутым кодом, и следующее улучшение перейдется от соединительной линии.

HotFix

Некоторые вещи, которые я еще не выяснил, - то, что происходит, когда там существует ответвление Dev, которое работается на и существуют текущие исправления, которые необходимы, чтобы быть сразу развернутыми.
Возможно, мы делаем отдельное ответвление из последней папки Release, называем ее Текущими исправлениями 3.0. Сделайте, чтобы разработчики сделали фиксацию, объединили ее с кодом Выпуска 3.0 после развертывания текущих исправлений и затем объединились с соединительной линией снова.

Вымыться

После того, как выпуск там не является действительно никакой потребностью иметь ответвления dev. Они должны быть удалены?

Так как мы переходим, я считал, что в VSS удаление ответвления не освобождает пространство в базе данных, если оригинал не удален.

Как мы должны удалить, или мы должны удалить ответвления dev?

Это мои мысли, как Вы управляете своими версиями и каковы Ваши рекомендации для моих требований.

Мы МОГЛИ БЫ перемещаться в TFS в будущем, таким образом, что-либо, что я реализую теперь в VSS, должно рассмотреть это перемещение в будущем.