SVN - Является ли неправильное создание ветки из ветки из ветки?

Ситуация: я видел практику, когда ветки SVN создаются из веток и продолжают работать. Например: Branch1 создан из TRUNK; Филиал2 из Филиала1; и т. д. См. ниже, чтобы получить представление:

.... продолжается и продолжается.......Ветвь 4 -- from--> Ветвь 3 -- from--> Ветвь 2 --from--> Ветвь 1 --from-->магистраль.

Таким образом, каждая новая ветка создается из последней ветки; вместо того, чтобы создавать его из Trunk или Main.

Вопросы:

  1. Является ли такая практика ошибочной?
  2. Это вызовет проблемы?
  3. Где-нибудь соблюдается такая практика?

Обновление: ответы на первый и третий вопросы удовлетворительны. Спасибо за помощь. Есть ли какие-либо проблемы, которых следует опасаться, особенно при использовании этого метода?


version-control branching-strategy svn svn-trunk
person sivv    schedule 17.07.2013    source источник
comment
SVN — это инструмент, который может поддерживать очень разные варианты использования, и могут быть варианты использования, для которых это хорошее решение. Это означает: сначала опишите свои варианты использования. Тогда легко объяснить, как вы можете поддерживать свои варианты использования с помощью SVN.   -  person nosid    schedule 18.07.2013
comment
Я понимаю. Я просто хотел убедиться, что практика сама по себе не является неправильной. Я понимаю, что в зависимости от требований это может быть правильным (или нет). Спасибо.   -  person sivv    schedule 24.07.2013

Ответы (1)


arrow_upward
0
arrow_downward

Является ли такая практика ошибочной?

No.

Это вызовет проблемы?

Нет новых типов проблем для слияний "туда и обратно", по сравнению со случаем "транк-посредник", но (возможно) *N старых типов (где N - количество синхронизированных ветвей)

Где-нибудь соблюдается такая практика?

Наверное да - это довольно распространенный случай и в нем нет ничего экзотического и иррационального

Примечание: я думаю, что использование автоматического слияния SVN 1.8 дает вам заметные преимущества в количестве необходимых операций при окончательной реинтеграции по сравнению с версией до 1.8 merge --reitegrate

person Lazy Badger    schedule 18.07.2013
comment
Это в значительной степени отвечает на мои вопросы. Пока это не совсем неправильно, я буду копать глубже и находить причины/преимущества (если таковые имеются) для такой практики. Спасибо за помощь. - person sivv; 24.07.2013
comment
Не могли бы вы немного рассказать о проблемах старого типа *N? - person sivv; 24.07.2013