Учитывая специфику системы (в т.ч. несовершенство средств разработки) 99% предложеных методик ведения кооперативной разработки будут далеки от идеала. Однако, это вариант позволояет установить баланс между скоростью разработки и сложностью его реализации. Он требует аккуратности от разработчиков, чем, к сожалению, большая часть последних не страдает
Г-н LedgerVoucher совершенно верно обратил внимание на документирование проектов. У меня, к примеру, есть такая мечта: иметь человека хорошо знающего ф-ть системы и имеющего хороший опыт программирования, который бы в Rational Rose рисовал склетон классов и все остального. Более того, были попытки проделывать эту операцию как на этапе анализа, так и перед этапом первого тестирования проекта. И в первом и во втором случае временные потери не оправдываются. Согласитесь, ведь если сборкой версии занимается достаточно опытный разработчик, знающий все горячие клавиши и быстро рулящий мышью, он, вероятнее всего, не будет пользоваться предложенной ему диаграмой. Ему проще поискать в коде текст коментариев, относящихся к проекту и сравнить слои приложения (usr и usp). Помоему, так.
Есть вариант вести список модифицированных элементов репозитария в экселе. Еще можно много чего придумать. Стоит ли?
imо, напрашивается вывод - сажать за сборку версии опытного разарботчика - относительно безболезненное решение.