Я, например, не понимаю как можно на одну ошибюку создвать отдельную ветку и зачем =(

Проблемы

На 14.11.2008 система сдачи исходных кодов неприемлема по следующим причинам:
— Очень сложно отслеживать изменения и находить полный вариант исходного кода, соответствующего исправлению данной ошибки (приходится просматривать логи);
— Изменения, произведенные компанией «Балтатсофт», приходится интегрировать вручную;
— Десинхронизация между исходным кодом «Балтатсофт» и эталонными исходными кодами «Accelya».

Возможные решения

Принять более жесткую методику, которая будет позволять:
— Быстро получать общие сведения об этапах развития eServices при помощи умелого использования менеджера исходных кодов (SVN);
— Упразднить всякую необходимость ручного вмешательства с целью отследить изменения исходных кодов;
— Обеспечить соответствие между исходным кодом «Балтатсофт» и эталонными исходными кодами «Accelya».



Сегодняшняя процедура сдачи-приемки работ

1- На каждое исправление ошибки или запрос об обновлении Accelya направляет в Балтатсофт файл спецификации.
2- Балтатсофт исправляет ошибки / производит обновления, затем тестирует сценарии, описанные в запросе.
3- Балтатсофт обновляет («commit» на языке SVN) измененные файлы, размещая их в своей ветке менеджера исходных кодов (SVN).
4- Балтатсофт по почте извещает Accelya, что задание выполнено и прилагает список измененных файлов по каждому запросу об исправлении ошибки.
5- Accelya вручную забирает файлы, перечисленные в списке, и интегрирует их в свой исходный код.
6- Accelya тестирует сценарии, указанные в запросе.
7- Accelya загружает обновления на серверы.



Желаемая процедура сдачи-приемки работ

1- На каждое исправление ошибки или запрос об обновлении Accelya направляет в Балтатсофт файл спецификации.
2- Балтатсофт создает по одной ветви на каждую группу ошибок / обновлений путем копирования ветви под названием «integration». Создаваемые ветви должны называться следующим образом: « bugX », где X – это номер ошибки / обновления, который фигурирует в спецификации.
3- Чтобы работать с ошибкой / обновлением, нужно заново сконфигурировать исходную папку, чтобы она переключилась на соответствующую ветку («switch» на языке SVN), затем обновить проект в Eclipse («refresh» на языке Eclipse), чтобы включить в него произведенные обновления.
4- Балтатсофт исправляет ошибки / производит обновления, затем тестирует сценарии, описанные в запросе.
5- На каждую исправленную ошибку:
a. Балтатсофт обновляет (« merge » на языке SVN) ветку «integration», интегрируя в нее все изменения из исправленной ветки;
b. Балтатсофт по почте извещает Accelya, что исправлена ошибка / произведено обновление;
c. Балтатсофт ожидает ответа Accelya прежде, чем проинтегрировать следующую ветку в ветку «integration».
6- Accelya тестирует сценарии, описанные в запросе, непосредственно в верви «integration».
7- Accelya утверждает произведенные изменения и применяет их к эталонной версии («trunk» на языке SVN).
8- Accelya загружает обновления на серверы.

Здравствуйте, EyfelFenk, Вы писали:

EF>Я, например, не понимаю как можно на одну ошибюку создвать отдельную ветку и зачем =(

ну во-первых выкладывать внутренние документы нехорошо
и возможно вам вскоре вставят "по самые помидоры" из первого отдела и лишат 13й зарплаты

Может после фикса бага создавать файл изменений svn diff параметры > Номер_Бага.txt
И прикладывать его к письму, либо к задаче в джире или что-там используется для баг-трекинга.

Здравствуйте, JohnWayne, Вы писали:

JW>Здравствуйте, EyfelFenk, Вы писали:

EF>>Я, например, не понимаю как можно на одну ошибюку создвать отдельную ветку и зачем =(

JW>ну во-первых выкладывать внутренние документы нехорошо
JW>и возможно вам вскоре вставят "по самые помидоры" из первого отдела и лишат 13й зарплаты

это не документы =) это дискуссия =)

Здравствуйте, sc, Вы писали:

sc>Может после фикса бага создавать файл изменений svn diff параметры > Номер_Бага.txt
sc>И прикладывать его к письму, либо к задаче в джире или что-там используется для баг-трекинга.

а зачем его вообще создвать если есть все в SVN?

Здравствуйте, EyfelFenk, Вы писали:

EF>Здравствуйте, sc, Вы писали:

sc>>Может после фикса бага создавать файл изменений svn diff параметры > Номер_Бага.txt
sc>>И прикладывать его к письму, либо к задаче в джире или что-там используется для баг-трекинга.

EF>а зачем его вообще создвать если есть все в SVN?

А зачем в svn ветку на баг создавать? Насколько я понял, кому-то неудобно ослеживать изменения. С диффом возможно будет удобнее. И код-ревью возможно удобнее. Быстрее. На одной из моих предыдущих работ примерно так и делали. Пользовали svn diff

Здравствуйте, EyfelFenk, Вы писали:

EF>это не документы =) это дискуссия =)

В любом случае просто так вот скопировать и запостить да еще и с названием фирмы — это весьма и весьма необдуманно.
Хочешь обсуждать — нет проблем, но сначала опиши проблему нейтрально и абстрактно.

P.S. Порой и в самом деле простота хуже воровства...

Здравствуйте, EyfelFenk, Вы писали:

Поищите описания как работают OpenSource проекты. Они используют патчи (Patch). Вам это тоже должно подойти.

Здравствуйте, EyfelFenk, Вы писали:

EF>Я, например, не понимаю как можно на одну ошибюку создвать отдельную ветку и зачем =(

Для SVN это вполне нормально, так как там не различается понятия branch (ветка) и label. И то и другое выполняется копированием в подпапку, и стоит одинаково дешево.

Другое дело, что в случае большого потока ошибок эта процедура накладна для обеих сторон. Я бы предложил месячные релизы, или чаще, если требуется — но с отсечкой по времени. Раз в период от транка делается ветка, которая проходит системный тест, и результаты отгружаются заказчику. Так все работают, схема описана в документации к SVN, и не понятно, зачем надо что-то изобретать. Ничего лучше человечество пока не придумало.

Здравствуйте, Gaperton, Вы писали:

EF>>Я, например, не понимаю как можно на одну ошибюку создвать отдельную ветку и зачем =(
G>Для SVN это вполне нормально, так как там не различается понятия branch (ветка) и label. И то и другое выполняется копированием в подпапку, и стоит одинаково дешево.
G>Другое дело, что в случае большого потока ошибок эта процедура накладна для обеих сторон. Я бы предложил месячные релизы, или чаще, если требуется — но с отсечкой по времени. Раз в период от транка делается ветка, которая проходит системный тест, и результаты отгружаются заказчику. Так все работают, схема описана в документации к SVN, и не понятно, зачем надо что-то изобретать. Ничего лучше человечество пока не придумало.

Согласен, вот у нас за один день уже 15 веток создана ужасть да и только. А объяснить людям не удается =( Для них-то все легко. Они с ветками не гемороются, они тока результат видят уже мигрирования в одной ветки =(

Здравствуйте, EyfelFenk, Вы писали:

EF>Я, например, не понимаю как можно на одну ошибюку создвать отдельную ветку и зачем =(

Объясню "зачем". Чтоб можно было просто внести/убрать функцию или фикс. Почему при обычной работе с trunk нельзя быстро откатить/накатить функционал? Потому что работа над фичей/багой не заканчивается на комите. А если нашли багу в реализации или фиксе? Нужен новый комит, если уже кто-то комитил в trunk, то работы по одной функции/баге разбросаны в разных комитах.
Ясно, что за это приходится платить усложнением процеса и небоходимостью поддерживать ветки.

Здравствуйте, KRA, Вы писали:

KRA>Здравствуйте, EyfelFenk, Вы писали:

EF>>Я, например, не понимаю как можно на одну ошибюку создвать отдельную ветку и зачем =(

KRA>Объясню "зачем". Чтоб можно было просто внести/убрать функцию или фикс. Почему при обычной работе с trunk нельзя быстро откатить/накатить функционал? Потому что работа над фичей/багой не заканчивается на комите. А если нашли багу в реализации или фиксе? Нужен новый комит, если уже кто-то комитил в trunk, то работы по одной функции/баге разбросаны в разных комитах.
KRA>Ясно, что за это приходится платить усложнением процеса и небоходимостью поддерживать ветки.

Нет, не ясно. Потому что нормальные люди для этого заводят по одной ветке на релиз, а не на исправление. Для любителей изобретать велосипеды об этом специально написано в документации к SVN.

http://svnbook.red-bean.com/nightly/ru/svn.branchmerge.commonuses.html#svn.branchmerge.commonuses.patterns

Управление версиями чаще всего используется при разработке программного обеспечения, поэтому здесь мы вкратце рассмотрим два наиболее часто используемых командами программистов приема ветвления/слияния. Если вы не используете Subversion для разработки программного обеспечения, можете пропустить этот раздел. Если вы — разработчик программного обеспечения, впервые использующий контроль версий, уделите этому разделу пристальное внимание, поскольку опытные разработчики считают использование данных приемов хорошим стилем. Такие приемы не являются специфичными для Subversion; они применимы к любой системе управления версиями. Однако, здесь мы взглянем на них с позиций Subversion.

Здравствуйте, Gaperton, Вы писали:

G>Нет, не ясно. Потому что нормальные люди для этого заводят по одной ветке на релиз, а не на исправление. Для любителей изобретать велосипеды об этом специально написано в документации к SVN.
Нормальные люди следуют здравому смыслу, а не слепо используют best practices, особенно когда они не работают в конкретных условиях

Я использую разные подходы в зависимости от проекта. Например, у нас есть проекты в которых нет обычных релизов, как совокупности каких-то новых фич. Каждая заявка от заказчика обрабатывается отдельно и неизвестно к каком порядке и когда заявка будет внедрена в основную ветку, т.к у заказчика сложный бизнес процес по внутреннему тестированию, согласованию и т.д. заявки. В этих проектах trunk соответсвует стабильной версии, которая стоит и заказчика на продуктиве. Для новой заявки создаётся своя ветка. Она сливается в trunk, тогда когда заказчик устанавливает соответсвующий патч на продуктив. До того она живёт в отдельной ветке или сливается в аналог ветки integration для тестирования.

G>http://svnbook.red-bean.com/nightly/ru/svn.branchmerge.commonuses.html#svn.branchmerge.commonuses.patterns

Вот цитата из преведённой Вами ссылки

В других проектах ветки используют по-другому: ни одного изменения не фиксируют в главной линии разработки напрямую. Даже для самых простых изменений создается краткосрочная ветка, внимательно анализируется и объединяется с главной линией. После чего ветка удаляется. Ценой огромных накладных расходов, такая система гарантирует исключительную стабильность и пригодность к использованию главной линии разработки в любой момент времени.

О чём я писал чуть другими словами.

Здравствуйте, KRA, Вы писали:

KRA>Здравствуйте, Gaperton, Вы писали:

G>>Нет, не ясно. Потому что нормальные люди для этого заводят по одной ветке на релиз, а не на исправление. Для любителей изобретать велосипеды об этом специально написано в документации к SVN.
KRA>Нормальные люди следуют здравому смыслу, а не слепо используют best practices, особенно когда они не работают в конкретных условиях

Не вижу никакого здравого смысла отступать от группировки нескольких изменений в один релиз, когда их капает по 15 штук в день. Это лишено смысла абсолютно — если вы мне скажете, что вы даете заказчику 15 дистрибутивов в день для проверки, я вам просто не поверю — любой разуменый заказчик просто пошлет такого исполнителя лесом. И не понимаю, что мешает выдавать один дистрибутив вместо пятнадцати, в котором находится сразу несколько исправлений.Тем более, что SVN позволяет исправлениями управлять индивидуально — там сквозная нумерация чекинов и с ними можно делать все что угодно. Такие безобразные схемы появляются от незнания инструмента, ИМХО.

Здравствуйте, Gaperton, Вы писали:

G>Здравствуйте, KRA, Вы писали:

KRA>>Здравствуйте, Gaperton, Вы писали:

G>>>Нет, не ясно. Потому что нормальные люди для этого заводят по одной ветке на релиз, а не на исправление. Для любителей изобретать велосипеды об этом специально написано в документации к SVN.
KRA>>Нормальные люди следуют здравому смыслу, а не слепо используют best practices, особенно когда они не работают в конкретных условиях

G>Не вижу никакого здравого смысла отступать от группировки нескольких изменений в один релиз, когда их капает по 15 штук в день. Это лишено смысла абсолютно — если вы мне скажете, что вы даете заказчику 15 дистрибутивов в день для проверки, я вам просто не поверю — любой разуменый заказчик просто пошлет такого исполнителя лесом. И не понимаю, что мешает выдавать один дистрибутив вместо пятнадцати, в котором находится сразу несколько исправлений.Тем более, что SVN позволяет исправлениями управлять индивидуально — там сквозная нумерация чекинов и с ними можно делать все что угодно. Такие безобразные схемы появляются от незнания инструмента, ИМХО.

Похоже Вы не прочитали внимательно моё сообщение. Повторюсь, бизнес процес заказчика делает невозможным включать изменения по разным заявкам в один дистрибутив. Заказчику они нужны отдельно. Я бы с радостью выкатывал один релиз, скажем, в две недели, в который бы включил все исправленные баги/добавленые фичи в этой итерации.
До маразма мы, кончено, не доводим. 15 веток в день не создаются. Я выше писал, что ветка создаётся для заявки (в стартовом сообщении фигурирует понятие "группа ошибок / обновлений"). Если по заявке обнаружена ошибка во время тестирования собственно реализации заявки, то правка ошибки просходит в ветке ошибки.