Если я понимаю вашу ситуацию, в ваших требованиях нет ничего, что могло бы сделать вещи настолько сложными, как вы, кажется, делаете их. Вы также уделяете слишком много внимания преимуществам автоматического и ручного объединения (подробнее об этом позже). Ветви CVS были бы другим делом, но не с тем, как SVN обрабатывает «ветки» (то есть, нет).
Вы можете иметь основную (нестабильную или стабильную) линию разработки и создавать ветки для каждого клиента или выпуска (или обоих). Поскольку функции проверяются, они либо возвращаются в основную строку, чтобы более поздние ветви могли включать эти изменения, либо вы всегда сливались однонаправленно из родительской ветви. Ничто не требует от вас закрытия ветви, и объединение не менее автоматизировано, чем это было бы для поддержки вашей первой (хаотичной) диаграммы, если у вас есть несколько параллельных линий разработки.
Требование, что вы объединяете только вперед, звучит так, как будто вам просто нужно объединить ревизии подмножества из основной строки, ревизии после данной ревизии ветви. Выполнение слияний таким образом позволит вам объединять изменения из произвольных ветвей обратно в основную линию так часто, как вам нравится (как они подтверждены вашими клиентами), и может применяться с уверенностью, что применяются только подтвержденные изменения. Вы можете настроить автоматическое слияние, чтобы отслеживать ревизию копии (см. --Stop-on-copy и слияния на основе диапазона). Затем отпустите ветви, чтобы получить набор подтвержденных изменений, которые произошли с данного момента вперед.
SVN не "отслеживает слияния" больше, чем поддерживает ветки (чего не происходит, это просто облегченные копии). Вы говорите ему (или svnmerge сообщает) диапазоны для слияния, и он применяет эти изменения. Вы можете получить эффект, который вам требуется по контракту для поддержки, независимо от того.
Чтобы ответить на поставленные вопросы:
Я не думаю, что предложенная вами модель очень эффективна. Напротив, он увеличил потенциал для хаоса отслеживания функций, так как вам, возможно, придется сканировать ветви на предмет изменений и объединяться вперед несколько раз. Более того, это, несомненно, запутает разработчиков, знакомых с SVN и более традиционными организационными структурами SVN.
Конечно. Это должно быть довольно независимым от структуры, которую вы выбрали. Вы будете нуждаться / хотите отслеживать ваши точки ревизии независимо (возможно, с помощью простого сценария в худшем случае).
Конечно. Филиалы фактически не имеют затрат в SVN на стороне сервера. На стороне клиента есть издержки, если вы делаете полную проверку корневого каталога, но это, как правило, глупо, несмотря ни на что. Аналогично, нет проблем с игнорированием / удалением ветки. Это просто еще одно изменение в глобальной иерархии ревизий, как и любое другое копирование / удаление / переименование / и т. Д.
Это должно работать независимо от "разветвленной" организационной структуры. Похоже, что, возможно, есть небольшое недопонимание того, что значит быть «ветвью» в SVN. Вы должны быть в состоянии настроить то, что вам нужно, и выполнить «ручные» слияния с относительной легкостью независимо, а затем настроить автоматическое слияние после нескольких обновлений клиентов, чтобы вы могли немного лучше понять шаги слияния.
Ура!