Столкнулся с проблемой.
Проект развивается довольно давно. Сейчас пришло время добавить некоторую функциональность. Для этого необходимо  внести кучу взаимосвязанных изменений в различных модулях и подсистемах. Одни изменения тянут за собой другие и получается так, что если мы хотим коммитить только работающий оттестированный код, то практически все изменения должен вносить один программист. Он же должен добавлять новые и корректировать старые тесты. Бред, какой-то, в общем   .
Добавление этого функционала довольно просто бьется на куски. И это уже сделано. Проблема во взаимоувязанности этих кусочков. Мне не до конца понятно, как организовать эти работы. Пока вижу такие варианты:

•  Как уже есть: коммитим только работающий код. Минусы - один человек вынужден тащить всю задачу. Плюсы - в trunk всегда работающая система. Работа одного человека над проектом - вообще тривиальный вариант. Можно вообще не коммитить   Если работают несколько и правильно. То первый коммит может родить новые тесты, которые не будут проходить. Дальнейшая работа будет постепенно «озеленять» тесты. Таким образом, этот вариант выглядит, по меньшей мере, странно.
  
•  Коммитим подзадачи, по мере их реализации. Несмотря на то, что проект в целом неработоспособен и тесты не проходят. Минусы - не работающая система в trunk'е. Требование одно - успешная компиляция. Никакое ночное автоматическое тестирование не организовать. В смысле, организовать, конечно же. Только оно не будет давать работающий код. Но этот вариант выглядит правдоподбнее в случае «правильной» работы - сначала тесты, потом все остальное.
  
•  разбиваем всю работу на задачи таким образом, что бы они а) были мелкие (можно сделать за 8 часов) б) не ломали проект. Минусы - много лишней работы, свазанной с требованием б. Нужно как-то или врастить изменения или изолировать их от рабочего кода. И эти «затычки» придется плодить в т.ч. в тех местах, которые в следующей задаче будут напрочь переделаны под новый функционал. Частенько такая подстановка костылей будет более прожорлива, чем основная работа. Так программисты могут разбежаться.
  
•  сделать ветку и работать в ней по п.2 Плюсы - в trunk'е по прежнему рабочий проект. Минусы - рабочий проект только в trunk'е. И довольно большое количество веток.

Как лучше поступить в описанной ситуации     ?

sandello, привет. давай попробуем разобраться.



даже самая мелкая подзадача потребует больших перемен в кодобазе?



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



ИМХО, это не вариант. Че-то я плюсов совсем не вижу   

Вобщем, я довольно близко наблюдал такой подход: в течение 3-ех недель один человек делал рефакторинг ОГРОМНОГО куска проекта, при этом все остальные добавляли новый функционал параллельно. Как? Очень просто. Он не коммитил ничего, но постоянно обновлялся и мерджил чужие изменения со своими. А потом закоммитил.

Думаю, что такой подход вполне себе будет работать и для твоего случая. Т.е. не парясь ты раздаешь задачи (при этом каждая должна делаться не дольше 8-ми часов), а программисты перед своими коммитам обновляются из транка и обеспечивают работоспособность того, что сделали другие, со своими изменениями. Будет трудно, ежики будут колоться, но кактус жрать надо   

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

Добавлено через 1 минуту и 19 секунд
Я больше склоняюсь к п.4 Лишней работы минимум. И очень похоже на описанный тобою вариант, только для группы разработчиков.

У нас (точнее в соседней команде) изменения делаются в ветке, и затем мержатся в транк. Причём зачастую мерж делает тим-лид, тем самым осуществляя и ревью кода. Веток бывает много, да, но в целом подход себя оправдывает.

Делать много локальных изменений и не коммитить - чревато последствиями - а ну как винт слетит.