Здравствуйте, maxim.ge, Вы писали:
MG>Версия1 => Версия2 => Версия3 => Версия4 и т.д.
MG>Т.е. каждая последующая версия ответвляется от предыдущей. trunk-а нет как такового.
MG>Не будет ли проблем с производительностью через некоторое время, ведь глубина ответвления все время будет увеличиваться ?
А в чем преимущество такой схемы перед схемой с trunk-ом + по ветке под версию?
Re: модель ветвления в subversion - не будет ли проблемы ?
MG>думаю в одном проекте сделать такую организацию веток MG>Версия1 => Версия2 => Версия3 => Версия4 и т.д.
Зачем такая организация, какую проблему решаете этим?
Re[2]: модель ветвления в subversion - не будет ли проблемы
L>А в чем преимущество такой схемы перед схемой с trunk-ом + по ветке под версию?
На мой взгляд, такая модель лучшее отображает реальность. В работе всегда есть несколько сборок, конкретно сейчас у меня по одному проекту B83 и B84, B83 в стадии RC, B84 только начата.
Понятие trunk мне представляется натянутым. Понятно, я могу считать, что trunk сейчас это B84, через некоторое время, когда B84 созреет, придется B84 "отстрелить" в ветку и считать, что в trunk сейчас B85, все это разъясняя разработчикам.
Но как-то это не прозрачно, на мой взгляд. Ветка на сборку — с этим понятно, а сущность "trunk" режется бритвой Оккама. Мне так кажется.
Re[2]: модель ветвления в subversion - не будет ли проблемы
Здравствуйте, LF, Вы писали:
MG>>думаю в одном проекте сделать такую организацию веток MG>>Версия1 => Версия2 => Версия3 => Версия4 и т.д. LF>Зачем такая организация, какую проблему решаете этим?
Здравствуйте, maxim.ge, Вы писали:
MG>На мой взгляд, такая модель лучшее отображает реальность. В работе всегда есть несколько сборок, конкретно сейчас у меня по одному проекту B83 и B84, B83 в стадии RC, B84 только начата.
MG>Понятие trunk мне представляется натянутым. Понятно, я могу считать, что trunk сейчас это B84, через некоторое время, когда B84 созреет, придется B84 "отстрелить" в ветку и считать, что в trunk сейчас B85, все это разъясняя разработчикам.
MG>Но как-то это не прозрачно, на мой взгляд. Ветка на сборку — с этим понятно, а сущность "trunk" режется бритвой Оккама. Мне так кажется.
По-моему все как раз ровно наоборот: есть запланированная последовательность работ, которая выполняется в trunk-е.
Когда выполнены все работы, относящиеся к версии, ставится метка. Когда нашли ошибки, которые нужно пофиксить в определенной версии, от метки отращивается ветка, в которой и фиксают ошибки.
Все просто и понятно зачем — у каждой сущности свое предназначение. SPR в действии.
Re: модель ветвления в subversion - не будет ли проблемы ?
Здравствуйте, maxim.ge, Вы писали: MG>Приветствую, MG>думаю в одном проекте сделать такую организацию веток MG>Версия1 => Версия2 => Версия3 => Версия4 и т.д. MG>Т.е. каждая последующая версия ответвляется от предыдущей. trunk-а нет как такового.
Меня тут немного смущает такой сценарий.
— От Версии2 делается feature-ветка.
— Внезапно принимается решение эту фичу перенести на неопределенный срок.
— В фича-ветку, ессно, надо регулярно вливать данные из текущей ветки: сперва это будет Ветка2, потом Ветка3 и т.п. А реинтегрить эту фичу мы вообще будем с Веткой5.
— Если бы ты использовал классический вариант релиз-веток, то фича-ветка (напротив) всегда синхронизировалась бы с транком.
Так что обязательно проверь, нет ли у svn проблем с таким сценарием.
Опять же, наличие транка говорит о существовании такого понятия, как "текущая разработка", в процессе которой постепенно формируется то, что становится "версией приложения". Если у вас процесс построен примерно так, то нет смысла переворачивать все с ног на голову.
MG>Не будет ли проблем с производительностью через некоторое время, ведь глубина ответвления все время будет увеличиваться ?
По идее, пофиг.
Re: модель ветвления в subversion - не будет ли проблемы ?
Здравствуйте, maxim.ge, Вы писали:
MG>Приветствую,
MG>думаю в одном проекте сделать такую организацию веток
MG>Версия1 => Версия2 => Версия3 => Версия4 и т.д.
MG>Т.е. каждая последующая версия ответвляется от предыдущей. trunk-а нет как такового.
MG>Не будет ли проблем с производительностью через некоторое время, ведь глубина ответвления все время будет увеличиваться ?
По опыту общения с SVN и не только.
Если одновременно есть несколько потоков разработки (несколько существенных фич в работе, несколько багрепортов) и при этом не известно, а что и когда выйдет — то лучше иметь несколько бранчей и не иметь транков.
Впрочем, четкого разделения версий не всегда получается, обычно есть бранчи "версионные" и бранчи с какой-то функциональность, к конкретной версии не привязанные. Ну и в какой-то момент происходит merge в конкретную версию.
Если поток разработки один — то лучше иметь выделенный транк.
Несколько сотен бранчей к провалу по производительности не приводят.
Re[4]: модель ветвления в subversion - не будет ли проблемы
Здравствуйте, Lloyd, Вы писали:
L>По-моему все как раз ровно наоборот: есть запланированная последовательность работ, которая выполняется в trunk-е. L>Когда выполнены все работы, относящиеся к версии, ставится метка. Когда нашли ошибки, которые нужно пофиксить в определенной версии, от метки отращивается ветка, в которой и фиксают ошибки.
L>Все просто и понятно зачем — у каждой сущности свое предназначение. SPR в действии.
Вот именно смотря на запланированное в трекере мне и пришла в голову несколько "дурная" идея "а зачем trunk".
Смотрите, какое простое получается описание процесса: вес работы делаются в ветке, указанной в записи трекера задач.
И все
Re[2]: модель ветвления в subversion - не будет ли проблемы
Здравствуйте, Mr.Cat, Вы писали:
MC>Меня тут немного смущает такой сценарий. MC>- От Версии2 делается feature-ветка. MC>- Внезапно принимается решение эту фичу перенести на неопределенный срок.
Ясно, то, что называется cherry-picking. Т.е. каждая задача сидит в своей ветке, потом по выбору они попадают в какую-то версию.
Но мне кажется, такой сценарий противоречит таким действиям:
MC>- В фича-ветку, ессно, надо регулярно вливать данные из текущей ветки: сперва это будет Ветка2, потом Ветка3 и т.п. А реинтегрить эту фичу мы вообще будем с Веткой5.
Если "ессно регулярно вливать" то все feature-ветки будут "загрязнены".
Ну т.е. мне так кажется feature-ветка должна разрабатываться изолированно а потом уже сливаться.
Но мы так вообще работаем на trunk в основном, так что в нашем случае эта проблема имеет в основном академический интерес.
Re[2]: модель ветвления в subversion - не будет ли проблемы
Здравствуйте, Дельгядо Филипп, Вы писали:
ДФ>Если одновременно есть несколько потоков разработки (несколько существенных фич в работе, несколько багрепортов) и при этом не известно, а что и когда выйдет — то лучше иметь несколько бранчей и не иметь транков.
Ага, спасибо, т.е. такой подход на практике используется, это важная информация.
ДФ>Несколько сотен бранчей к провалу по производительности не приводят.
Меня смущают тут не сотни бранчей, у меня их еще больше сейчас, а то, что они последовательно растут друг из друга. Сейчас ветки от ствола далеко не отклоняются, а будут,
Re[5]: модель ветвления в subversion - не будет ли проблемы
Здравствуйте, maxim.ge, Вы писали:
MG>Вот именно смотря на запланированное в трекере мне и пришла в голову несколько "дурная" идея "а зачем trunk".
MG>Смотрите, какое простое получается описание процесса: вес работы делаются в ветке, указанной в записи трекера задач.
MG>И все
Еще проще: все работы, если не указано иное (т.е. 90%) делаются в trunk-е. Проще некуда.
Версия вообще не должна быть заботой девелопера, это не относится к его работе, версия — это о планировании.
Re[3]: модель ветвления в subversion - не будет ли проблемы
MG>Ну т.е. мне так кажется feature-ветка должна разрабатываться изолированно а потом уже сливаться.
совсем нет, фичаветка может и должна постоянно обновляться уже принятыми и протестированными задачами.
Re[6]: модель ветвления в subversion - не будет ли проблемы
Здравствуйте, Lloyd, Вы писали:
L>Еще проще: все работы, если не указано иное (т.е. 90%) делаются в trunk-е. Проще некуда.
Так именно с оставшимися 10% процентов и возникают проблемы. Их исключение из описания упрощает, конечно, описание, но таким описанием в реальности пользоваться будет нельзя
Re[7]: модель ветвления в subversion - не будет ли проблемы
Здравствуйте, maxim.ge, Вы писали:
L>>Еще проще: все работы, если не указано иное (т.е. 90%) делаются в trunk-е. Проще некуда.
MG>Так именно с оставшимися 10% процентов и возникают проблемы. Их исключение из описания упрощает, конечно, описание, но таким описанием в реальности пользоваться будет нельзя
Вау, мы делаем невозможное.
Re[4]: модель ветвления в subversion - не будет ли проблемы
Здравствуйте, LF, Вы писали:
MG>>Ну т.е. мне так кажется feature-ветка должна разрабатываться изолированно а потом уже сливаться. LF>совсем нет, фичаветка может и должна постоянно обновляться уже принятыми и протестированными задачами.
Если мы хотим иметь возможность переносить фичи на неопределенный срок, а именно такой сценарий рассматривается, то мы должны ветки держать изолированно до последнего момента. Соответственно, в таком подходе в trunk нет протестированных задач, они сидят по веткам и ждут финального отбора. Разве нет ?
Re[8]: модель ветвления в subversion - не будет ли проблемы
Здравствуйте, Lloyd, Вы писали:
MG>>Так именно с оставшимися 10% процентов и возникают проблемы. Их исключение из описания упрощает, конечно, описание, но таким описанием в реальности пользоваться будет нельзя
L>Вау, мы делаем невозможное.
Ну если в этих самых 10% вы ничего не делаете, то да У меня так не получается.
Re[9]: модель ветвления в subversion - не будет ли проблемы
Здравствуйте, maxim.ge, Вы писали:
MG>>>Так именно с оставшимися 10% процентов и возникают проблемы. Их исключение из описания упрощает, конечно, описание, но таким описанием в реальности пользоваться будет нельзя
L>>Вау, мы делаем невозможное.
MG>Ну если в этих самых 10% вы ничего не делаете, то да У меня так не получается.
Да вроде как делаем.
Re[3]: модель ветвления в subversion - не будет ли проблемы
Здравствуйте, maxim.ge, Вы писали: MG>Ясно, то, что называется cherry-picking. Т.е. каждая задача сидит в своей ветке, потом по выбору они попадают в какую-то версию.
Не так важно, как это называется. Важнее, насколько трудно будет сделать merge. Вероятно, в описанном сценарии проблем не будет. Но мало ли что.
MG>Если "ессно регулярно вливать" то все feature-ветки будут "загрязнены". MG>Ну т.е. мне так кажется feature-ветка должна разрабатываться изолированно а потом уже сливаться.
Загрязнены чем? Это стандартная практика — регулярно обновлять фича-ветку, вливая туда изменения из транка. Контент транка — это то, с чем девелоперу фичи, как ни крути, нужно жить, т.к. фича разрабатывается под транк (то, что надо изолировать от других фич — это тоже фича). И гораздо лучше, если девелопер фичи будет получать изменения транка по мере их возникновения, чем если они придут ему пачкой перед реинтеграцией.
Re[5]: модель ветвления в subversion - не будет ли проблемы
Здравствуйте, maxim.ge, Вы писали: MG>Если мы хотим иметь возможность переносить фичи на неопределенный срок, а именно такой сценарий рассматривается, то мы должны ветки держать изолированно до последнего момента.
Изолированно от кого? Друг от друга — да, фичи будут изолированы. От транка — нет. Даже если в фиче уже не идет разработка, ее надо синхронизировать с транком по мере его изменения.
MG>Соответственно, в таком подходе в trunk нет протестированных задач, они сидят по веткам и ждут финального отбора.
В транке все равно будут появляться общие для всех фич изменения. Исправления багов, мелкие фичи без собственных веток, реинтегрированные другие фичи и т.п.
