забавно - час назад спрашивал своего тимлида про это же самое, вернее почему так много бранчей (всего 4, но с архаичными cvs и даже svn это уже много).
бранчи - большой геморрой, но как быть когда система крутится у нескольких клиентов, и не каждый клиент хочет какие-либо новые фичи? И немного другая ситуация - как быть когда один клиент хочет конкретные фичи? Если у кого-нибудь есть способ разруливать подобные ситуации, пожалуйста поделитесь. Заранее скажу, система весьма и весьма гибкая, настройки в принципе в БД, т.е. система может на лету менять поведение (при смене класса реализации какой-либо бизнес-логики).

HauerSarkand,

Есть у меня опыт такой и вот, что я скажу. Делать разные ветки это самоубийство. Возможно, какое-то время это и будет удаваться поддерживать ценой неимоверных усилий, но не думаю, что очень долго.
Довольно быстро, я боюсь, "слияние" станет проходить очень непросто, а местами будет выливаться в переписывание всех веток.

Вообщем, делайте одну ветку и настройками приложения/сборщика, как, собственно, все и советуют.

Kostya Ilyinov,

Если хочет конкретные фичи - добавляйте в основную ветку, но включайте только для одного клиента, какие проблемы?

Хехе интересная идейка - как я сразу не догадался :-)
Сценарий:изначально есть один продукт, модуляризованный и гибконастраиваемый. Есть регион допустим А, где продукт успешно внедрен и эксплуатируется. В регионе А продолжается разработка, и на какой-либо момент времени, имелся продукт А1 с набором дополнительных функций (фич так сказать). Затем в регионе Б решают внедрить данный продукт - все легко и просто - тот же код, только разные настройки. Все работает прекрасно. В регионе А меняется законодательство, необходимо внедрить функциональность А2. Пользователя продукта А1 в регионе Б эти изменения не касаются, и соответственно внедрять какие-либо изменения в работающую (и приносящую деньги) систему никто не собирается (после внесения изменений систему нужно протестировать - зачем тестировать систему(тратить деньги) на неиспользуемый функционал?). Имеем - изменения для А2 должны быть изолированы от других регионов. Думаю дальнейший исход событий с 4 регионами и весьма различающейся конъюнктурой понятен. Уверен, мы не одни в такой ситуации, поэтому ход мыслей должен быть понятен. В идеальном мире с pluggable архитектурой конечно можно было инвестировать в еще более гибкую систему и т.д. и т.п. - но в реальном мире всегда есть камень преткновения, препятствующий использованию единого кода для разных регионов/инсталляций.

softwarer,

не хотелось бы переходить на личности - я Вам изложил, вполне доступно думаю, имеющуюся ситуацию - а Вы мне про прописные истины тут рассказываете, наследование, нормальный подход и т.д. Уверен у нас эти принципы ООП используются, но как я уже сказал - в реальном мире все не так просто, и рефакторить работающую систему дело довольно затратное. Конечно, если бы у нас было хотя бы 50 клиентов - дело бы шло иначе, мы бы обязательно привлекли вас к проектированию архитектруры - а так приходится довольствоваться низкоквалифицированными выпускниками ПТУ. Хотел было посмотреть Ваше (не уверен на 100%) резюме ( http://softwarer.ru/resume.html) - но там 404 :-(

softwarer,

Большое спасибо за ваше так сказать напутствие (серьезно). Вы я вижу весьма умный человек и хороший программист в частности - поэтому думаю Вам будет интересно познакомиться (а может и не будет/а может и не познакомиться) с концепциями и терминами Time To Market, Technical Debt - думаю это прольет свет на разработку приложений для проклятого капитализма. Если интересно, могу дать чуть больше конкретики - думаю если не Вам, то сообществу будет весьма интересно. Имеем систему, позволяющую проводить базовые банковские операции при помощи обычного j2me телефона. Система успешно разработана под ключ так сказать для одного клиента. Затем успешно внедрена еще у нескольких - естественно с какими-то индивидульными доработками и потребностями. Все хорошо работает и весьма неплохоспроектировано. Есть точки расширения и другие механизмы тонкой и грубой настройки. Затем типовую систему внедряют в Индию - опять же с небольшими изменениями в настройках и т.д. Код везде один - отличаются лишь настройки. В Индии решают внедрить пилотный проект по использованию телефона для бронирования авиа/кинобилетов - на данный момент в других регионах эта функциональность не востребована - и вряд-ли когда-либо будет - так исторически сложилось - каждый занимается (весьма преуспевающе) своим делом. Имеем дилемму - точки расширения для данного сценария нет, необходимо вносить изменения в архитекуру одного из базовых модулей. Пути решения - либо вносить изменения в транк (главную ветку), и уговаривать всех клиентов обновлять систему(маловероятно) без измений функциональности (еще менее вероятно), либо отделяться от главной ветки и менять так сказать индийскую ветку. Да, возможно нужно было больше инвестировать в разработку архитектуры и предусмотреть все мыслимые и немыслимые, но требования бизнеса весьма жесткие - функциональность должна быть внедрена как можно раньше, иначе компания рискует потерять все инвестиции в бизнес-идею. Думаю сценарий весьма типовой - концепция технического кредита именно с таким прицелом и была сформулирована - это кредит, и необходимо платить проценты (подчас весьма высокие) - в нашем случае эти проценты гасятся геморроем во время слияний веток разработки. Сейчас планируем все вернуть на круги своя - ну а до тех пор - git нам в помощь :-)