контроль версий: CVCS или DVCS?
 

Какой системой контроля версий (Version Control System) пользуетесь для коммерческих проектов:
1) Centralized VCS (SVN, CVS, ...)
2) Distributed VCS (Git, Mercurial, ...)
?

честно говоря не понял приемущества git/mercual, кроме "лёгких" комитов. в svn это решал с помощью release/test серверов. Которые сами по себе только клиенты и качали нужную ревизию.
Распределённость тоже не сть хорошо. Для работы в команде по-любому нужен централ.

Таки SVN.

Как я понял преимущества еще и в "легких" merge (в CVCS это был "pain in the ass"), возможность работать независимо от централа (например без инета).
А вообще мне кажется было бы здорово заюзать что-то среднее между CVCS и DVCS, т.е. минорные изменения коммитим в свой локальный реп, а законченные фичи - в централ. Кто-нибудь встречал подобное?

Централ и так по любому есть и у SCN и у GIT, только с гитом можно камититься и без наличия коннекции к централу. Кроме того, т.к. у каждого члена команды есть копия централа, то повышается сохранность данных по отношению к сбоям серевера на котором хранится "централ".

Встречал, в гите есть возможность отбранчить новую ветку, ваять в ней, а когда изменения в ней переросли в фичу, мержить свою фичу в главную ветку.

Пользуюсь GIT; с того момента как перешли с Subversion на GIT не было дня, когда что-нубудь случайно не сломалось. Начиная с того, что сервер документации не получается настроить на работу с ним, так еще и чисто организационные вопросы (кто внес последние правки? куда делись изменения? почему файлы origin сидят в репозитори? и так без конца). Общий уровень понимания происходящего и владения ситуацией среди рабочего персонала снизился практически до нуля. Тривиальная раньше задача, типа вытащить случайно удаленный 10 версий назад файл из репозитория стала совсем не такой тривиальной и т.д. Из самых плохих последствий, не возможно оперативно определить тестирует ли QA последний билд или нет. Вобщем если вам не хватало хаоса в повседневной жизни - перейдите на GIT, как минимум несколько часов брейнсторминга посвященного решению самых тривиальных задач в день вам обеспечено.

К автору опроса: пожалуйста добавьте опций. Потому что если я чесно признаюсь, что использую GIT, это ему поднимет репутацию, а я совсем этого не хочу.

Это все симптомы самой общей проблемы смены рабочего инструмента, а не проблемы гита как такового. Адекватно оценить инструмент можно только полностью им овладев, то есть спустя время. Крепитесь, грызите гранит, и скоро попустит и даже станет лучше чем було. Удачи.

Я не хочу им овладевать, мне, для того, чтобы писать мои проекты это вообще не нужно (Я не хочу заниматься допиливанием и "файн-тюнингом" инструментов, мне хватает того, что нужно допиливать IDE). К Subversion не нужно было привыкать, потому, что это просто удобный инструмент. Git - это интересно, но в производсвте не пригоден пока ни на что.

EDIT: Или, скажем по-другому, vim - замечательный редактор... для 0.0001% програмистов. В написании сколь-нибудь сложных проектов не применим в приниципе. Потому что если програмисты начнут гуглить "как скопипастить произвольный текст", то работа встанет. Точно так же и Git. Если хочется с комфортом, без головной боли просто работать, то про него можно забыть.

кмк первый стейтмент перевесит любые доводы :)
допиливать его не надо, надо сделать памятку - что-то вроде этого, но короче и раздать команде.
гит используют в таких немаленьких проектах, как: Linux Kernel, Perl, Eclipse, Gnome, KDE, Qt, Ruby on Rails, Android, PostgreSQL, Debian, X.org.

GIT. (сам только начинаю им пользоваться)

для тех кто интересуется, можно начать с хабра:

Почему Git
Про Git на пальцах (для переходящих с SVN)
Git Workflow
Git Wizardry
Использование git во Flash разработке