Если кто-то что-то совсем сломал, его коммит можно просто откатить — с этим справится любой другой программист. :) Это бывает, но не настолько часто, чтобы ради этого менять процесс и сильно усложнять всем жизнь.
Серверные бранчи для фич мы не используем потому, что не видим в этом необходимости. :) У нас вообще редко бывает такое, что девелопер долго (несколько недель) делает какую-то большую фичу в существующем коде. Активный девеломпент идёт либо в плагинах (которые нет смысла выносить в отдельные бранчи — и так никому не мешает), либо в виде кучи мелких изменений в разных местах.
Changeset'ов в репозитории дохрена и более — мы когда переходили на git, засосали туда всю историю из perforce и subversion, то есть все коммиты с начала 2005 года. Клонирование занимает, наверное, час-полтора, но это как раз не особенно напрягает: это приходится делать один раз в начале работы, один раз при создании бранча для новой версии, и тогда, когда совсем всё сломалось.
Да, это per branch. Репы типа линуксового ядра живут совсем по-другому: там для каждого репозитория есть очень мало человек, которые туда push'ат, а сборка всего в кучу делается через явный ручной pull из кучи разных репозиториев в мастер-репозиторий Линуса.
Про графический интерфейс пока не обещаем. Для git'а мы кое-что сделали, но оно пока не шарится с другими VCS.
Итераций как таковых у нас нету. Локальные бранчи используются на усмотрение разработчиков — если кому надо, он сам себе заводит, а кому не надо, тот прямо в мастер всё фигачит. Плюс, конечно, есть параллельная ветка (иногда две) на предыдущий major release, куда каждый свои фиксы переносит через git cherry-pick, или сразу после исправления проблемы, или потом по мере необходимости.
Официальная поддержка Mercurial (на базе hg4idea-luciad плюс куча наших фиксов и доделок) будет в IDEA 10.
Сложности с git вытекают в первую очередь из того, что он версионирует репозиторий целиком, поэтому даже для того, чтобы запушить один маленький файлик, нужно иметь up to date версию всего репозитория. Если запушить нужно срочно (например, компиляцию починить), а в это время 30 коллег пушат в тот же репозиторий какие-то свои change'и — апдейтиться часто приходится по нескольку раз. При этом кода дофига, и каждый апдейт может занимать минуты (особенно под Windows).
Удалять тесты у нас не принято; удаляем только в том случае, если они тестируют вообще непонятно что, или если после переделки от того, что они тестируют, ничего узнаваемого не осталось. Стараемся чинить. Если чинить не получается — муваем в специальную группу «тесты, про которые мы знаем, что они иногда падают», в которой они продолжают иногда падать, пока кому-нибудь не станет не лень разобраться.
Тестеры-то смогли писать функциональные тесты — скорее оказалось, что это не самая эффективная трата их времени. Ручное тестирование позволяет найти больше интересного.
Тестеров у нас мало — в IDEA их на данный момент четверо на ~ 25 девелоперов.
Тесты у нас обычно находят ошибки класса «разломали чего-то в процессе переделки». В штуках их, конечно, намного меньше, чем багрепортов от пользователей и наших собственных тестеров, но важность их часто бывает сильно больше. Но много и ложных срабатываний — тестов, которые падают потому, что плохо написаны, а не потому, что в продукте что-то сломалось.
Функциональные тесты пишут обычные разработчики; мы пытались привлекать к этому тестеров, но как-то не очень пошло. Покрытие — вот сейчас посмотрел, показометр показывает 45%, но мы на эту цифру смотрим редко и целенаправленным её увеличением не занимаемся. Вносить осмысленные изменения в тесты при переделках архитектуры приходится очень редко, что нас весьма радует.
Серверные бранчи для фич мы не используем потому, что не видим в этом необходимости. :) У нас вообще редко бывает такое, что девелопер долго (несколько недель) делает какую-то большую фичу в существующем коде. Активный девеломпент идёт либо в плагинах (которые нет смысла выносить в отдельные бранчи — и так никому не мешает), либо в виде кучи мелких изменений в разных местах.
Changeset'ов в репозитории дохрена и более — мы когда переходили на git, засосали туда всю историю из perforce и subversion, то есть все коммиты с начала 2005 года. Клонирование занимает, наверное, час-полтора, но это как раз не особенно напрягает: это приходится делать один раз в начале работы, один раз при создании бранча для новой версии, и тогда, когда совсем всё сломалось.
Итераций как таковых у нас нету. Локальные бранчи используются на усмотрение разработчиков — если кому надо, он сам себе заводит, а кому не надо, тот прямо в мастер всё фигачит. Плюс, конечно, есть параллельная ветка (иногда две) на предыдущий major release, куда каждый свои фиксы переносит через git cherry-pick, или сразу после исправления проблемы, или потом по мере необходимости.
Сложности с git вытекают в первую очередь из того, что он версионирует репозиторий целиком, поэтому даже для того, чтобы запушить один маленький файлик, нужно иметь up to date версию всего репозитория. Если запушить нужно срочно (например, компиляцию починить), а в это время 30 коллег пушат в тот же репозиторий какие-то свои change'и — апдейтиться часто приходится по нескольку раз. При этом кода дофига, и каждый апдейт может занимать минуты (особенно под Windows).
Тестеры-то смогли писать функциональные тесты — скорее оказалось, что это не самая эффективная трата их времени. Ручное тестирование позволяет найти больше интересного.
Тестеров у нас мало — в IDEA их на данный момент четверо на ~ 25 девелоперов.
Функциональные тесты пишут обычные разработчики; мы пытались привлекать к этому тестеров, но как-то не очень пошло. Покрытие — вот сейчас посмотрел, показометр показывает 45%, но мы на эту цифру смотрим редко и целенаправленным её увеличением не занимаемся. Вносить осмысленные изменения в тесты при переделках архитектуры приходится очень редко, что нас весьма радует.