[maxkar]

То есть так. Сначала создадим новый репрозиторий, в него через svn export делаем экспорт текущей рабочей копии.

Не совсем. Сначала через svn export вы получаете чистую (без привязки к репозиторию) копию проекта. Затем через svn import заливаете ее в репозиторий. Далее уже примерно так, как вы описали. Через svn checkout дает первую ревизию. Дальше можно с ней работать и коммитить. Правки после успешного коммита появляются на сервере и видны всем. Перед удалением/переносом файлов/каталогов рекомендуется делать еще svn up, иначе будет ругаться на tree conflict (есть особенности версионирования каталогов).

Далее - как решается вопрос тестирования?

Если правильно, то svn checkout/svn update/svn export из репозитория, автоматическая сборка всего проекта и его тестирования.

Если я хочу выгрузить файлы на сервер и там запустить (учитывая, что в проекте сотни файлов, без публикации на domain.com, само собой, итд),

Т.е. без коммита? Ну собираете у себя и вручную заливаете. Проблем особых нет.

и как решить вопрос с публикацией только основательно проверенных и стабильных revision(делать ответвления, их тестить, потом сливать)?

Ну да, можно так. Я замечу здесь, что вы путаете коммиты и release policy. Это совершенно разные аспекты управления проектами и выполняются по-разному. Можно вполне публиковать в репозиторий и непроверенные вещи, все зависит от методики управления проектом. Подробнее про release management здесь.

жет, кто-то опишет, как именно у них работают с SVN на проекте?

Официальную теорию уже читали? Конкретно у нас все изменения идут в trunk. Перед релизом объявляется feature freese, все проверяется, баги правятся (в том же trunk). В момент релиза trunk сливается в ветку current (можно копированием, можно - merge, в самом первом релизе current создается копированием trunk'а) и заводится отдельный тег. Продукт заливается на боевые сервера. После этого можно опять гадить в trunk. Ну и отдельно проходит процедура hotfix для боевой версии. В этом случае патч делается в current, из current же собирается новый релиз и потом правка портируется (мержится) в trunk. Отдельные ветки под фичу - только по мере необходимости (если там что-то большое, делается долго и ломает совместимость). Это далеко не единственный вариант управления изменениями, могут быть и различные другие. Этот был выбран под наши сценарии и нашу команду.