Отправить исправления ошибок на панели запуска с помощью исправлений или предложений по слиянию?

Я новичок в Launchpad и Bazaar, и я пытаюсь выяснить, как лучше всего отправлять исправления ошибок. Я использую довольно популярное программное обеспечение с открытым исходным кодом, размещенное на Launchpad, но оно не очень стабильно. Я создал свою собственную ветку проекта, чтобы стабилизировать его и применить только необходимые исправления ошибок, не добавляя другие изменения из текущей разработки.

Когда я сообщаю об ошибках, а затем выясняю, как их исправить, я отправляю исправление в нашу стабильную ветку. Как мне опубликовать исправление обратно в основной проект? Я мог бы создать патч-файл и прикрепить его к ошибке или предложить слияние для нашей стабильной ветки.

Если я исправляю несколько ошибок, могу ли я сделать отдельное предложение по слиянию для каждой из них, или они суммируются?


person Don Kirkby    schedule 22.01.2010    source источник
comment
Ваш проект размещен на Launchpad?   -  person bialix    schedule 23.01.2010
comment
Да, @bialix, проект размещен на Launchpad.   -  person Don Kirkby    schedule 26.01.2010
comment
Тогда объединить предложения будет самым естественным образом. Для эффективной работы с ними требуется некоторая подготовка, но в целом они мне очень пригодились.   -  person bialix    schedule 26.01.2010


Ответы (2)


Обновление: похоже, что в официальной документации проекта OpenERP теперь есть рекомендации по внесению предложений о слиянии. Я также оставлю свою версию здесь, потому что в ней есть некоторые другие детали.

Поиграв несколько дней с Bazaar и Launchpad и представив несколько исправлений и предложений по слиянию, я решил написать краткое изложение того, что я нашел. Launchpad и Bazaar предоставляют несколько мощных инструментов, особенно для проектов, управляемых сообществом, но я не думаю, что новые пользователи, вероятно, попасть в ловушку успеха. Есть несколько способов сделать процесс медленным и разочаровывающим, поэтому я надеюсь, что это пошаговое руководство поможет некоторым людям избежать нескольких ошибок.

Вот рабочий процесс, который я изучил для работы над исправлениями ошибок и отправки предложений по слиянию обратно в команду для проекта, размещенного на Launchpad. Я работаю на рабочей станции GNU/Linux, но предполагаю, что команды Bazaar будут эквивалентны на других платформах. В этом примере я работаю над одним из проектов в группе проектов OpenObject под названием OpenObject Addons. Имя пользователя сопровождающего — openerp. Я помещу свое рабочее пространство в папку ~/workspace.

Если вы хотите узнать больше о какой-либо из приведенных здесь команд, используйте bzr help плюс имя команды.

Создать общий репозиторий

Поскольку я собираюсь создать ветку для каждой функции, которую я хочу внести в проект, я не хочу иметь отдельную копию всей истории проекта для каждой ветки. Чтобы избежать этого, я создаю общий репозиторий, а затем создаю в нем каждую ветку. Одна вещь, с которой следует быть осторожным, это то, что формат вашего репозитория должен соответствовать формату официальной ветки, чтобы некоторые из последующих шагов работали.

Проверьте формат репозитория на официальной ветке:

bzr info http://bazaar.launchpad.net/~openerp/openobject-addons/5.0

Получить код

Теперь создайте папку рабочей области, в которой будут храниться все локальные ветки на вашем компьютере — я просто назову ее в честь проекта. Затем создайте в нем общий репозиторий, используя формат, который вы нашли в официальной ветке.

cd ~
mkdir workspace
cd workspace
mkdir openobject-addons
cd openobject-addons
bzr init-repo --format=rich-root-pack .

Следующим шагом будет проверка исходного кода из официальной ветки. Обычно его называют транком, но вы можете предпочесть работать со стабильной веткой выпуска, которая используется только для исправления ошибок. В этом примере я буду работать над веткой релиза 5.0.

cd ~/workspace/openobject-addons
bzr checkout lp:~openerp/openobject-addons/5.0/ feature-x

Этот шаг, вероятно, самый медленный во всем процессе для большого проекта, потому что вы копируете весь код плюс всю историю всего проекта на свой жесткий диск. Обратите внимание, что я называю ветку в честь функции, над которой собираюсь работать.

Создать ветку

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

После того, как вы настроили свою учетную запись, вы можете опубликовать свою собственную ветку как копию официальной ветки и начать с ней работать. Команда lp-login сообщает bazaar, какое имя учетной записи использовать на сайте панели запуска, а команда whoami сообщает bazaar, какое имя использовать для каждой ревизии, которую вы фиксируете. Адрес электронной почты, который вы используете в whoami, должен совпадать с одним из адресов электронной почты, настроенных для вашей учетной записи Launchpad.

cd ~/workspace/openobject-addons/feature-x
bzr lp-login donkirkby
bzr whoami "Don Kirkby <[email protected]>"
bzr branch --stacked --switch lp:~openerp/openobject-addons/5.0/ lp:~donkirkby/openobject-addons/feature-x

Вы переключаетесь на новую ветку, чтобы коммиты записывались в вашей локальной истории и в вашей публичной ветке. Вы можете узнать о разнице между кассой и филиалом. Создание ветки с накоплением означает, что ее очень быстро создать, потому что она содержит только историю, которой нет в официальной ветке. Это сообщение в блоге похоже на ветки общедоступных проектов должны по умолчанию быть сложенными, но это не сработало для меня. Обратите внимание, что я назвал ветку в честь функции, которую хочу добавить. Как предложил bialix, Я создаю отдельную ветку для каждой функции, которую в конечном итоге предложу снова объединить с официальной веткой.

Подтвердить и сделать предложение о слиянии

Теперь, когда у вас есть ветка, вы можете внести изменения в код и зафиксировать их.

cd ~/workspace/openobject-addons/feature-x
bzr commit -m "Fixed bug lp:12345 by fleaking the woverbinate() function."

Вы можете зафиксировать из любого места в структуре ветки, и по умолчанию она фиксирует всю ветку. Запустите bzr help commit для получения подробной информации. Вам также могут пригодиться bzr status и bzr diff.

Когда вы будете довольны изменениями и зафиксируете все в своей функциональной ветке, вы можете перейти на веб-сайт Launchpad и создать предложение о слиянии. Вот удобный ярлык, который вы можете запустить для запуска веб-страницы филиала:

cd ~/workspace/openobject-addons/feature-x
bzr lp-open

Как только вы создадите предложение о слиянии, Launchpad создаст для него diff. Стоит пересмотреть этот diff. Иногда я выбирал неправильную ветку в качестве цели и замечал это только потому, что в diff было гораздо больше изменений, чем я ожидал. Также есть команда bzr send для предложений о слиянии, но я ей не пользовался.

Существует интерфейс электронной почты для сопровождения вашего предложения на протяжении всего процесса, или вы можете просто использовать Веб-сайт.

Также полезно прикрепить ветку к ошибке, чтобы другие люди могли использовать ее как патч на своих системах.

Текущие изменения

Если вы работаете над несколькими функциями, а сопровождающий не очень быстро рассматривает ваши предложения, вероятно, стоит создать свою собственную основную ветку. Эта ветвь собирает вместе все ваши функции и содержит код, который вы будете запускать на своих серверах. Это также полезно, если официальная ветка не очень стабильна, и вы хотите стабилизировать ветку для своей производственной среды. Затем вы можете решить, когда обновляться до последней версии, а когда использовать определенные исправления для ошибок, которые вредят вашим пользователям.

Первый шаг — создать еще одну ветку, которая будет наложена на официальную ветку:

cd ~/workspace/openobject-addons
bzr checkout lp:~openerp/openobject-addons/5.0/ main
cd main
bzr branch --stacked --switch lp:~openerp/openobject-addons/5.0/ lp:~donkirkby/openobject-addons/main

Теперь есть два источника изменений, из которых вам нужно выполнить слияние. Во-первых, слияние из ветки функции или исправления ошибки:

cd ~/workspace/openobject-addons/main
bzr merge lp:~donkirkby/openobject-addons/feature-x/
bzr commit -m "Merged feature x"

Конечно, если у вас все еще есть локальная копия ветки функций, будет быстрее сделать локальное слияние:

cd ~/workspace/openobject-addons/main
bzr merge ../feature-x
bzr commit -m "Merged feature x"

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

cd ~/workspace/openobject-addons/main
bzr merge --remember lp:~openerp/openobject-addons/5.0/
bzr commit -m "Merged from 5.0 branch"

После использования --remember при слиянии с официальной веткой вы можете просто использовать bzr merge отдельно для слияния с официальной веткой. Если в проекте используются теги для обозначения точек выпуска, вы можете просмотреть список тегов и выполнить слияние из тега.

cd ~/workspace/openobject-addons/main
bzr tags -d lp:~openerp/openobject-addons/5.0/
bzr merge -r tag:5.0.7rc2
person Don Kirkby    schedule 28.01.2010
comment
Это хорошее резюме. Но почему вы решили использовать bzr branch --stacked вместо bzr push? - person bialix; 29.01.2010
comment
@bialix, когда я использовал bzr push, это заняло целую вечность. Я предполагаю, что он копировал полный репозиторий в мою новую общедоступную ветку. bzr branch --stacked занимает всего несколько секунд, потому что копирует некоторые метаданные и больше ничего. Это звучит правильно для вас? - person Don Kirkby; 29.01.2010
comment
push стек по умолчанию на фокус развития ветки, но вам кажется, что он выбирает неправильную ветку. Тем не менее: да, ваш подход в этом случае правильный. - person bialix; 29.01.2010
comment
Только что проверил. Да, по умолчанию push будет складываться на lp:openobject-addons, но вы хотите складывать на lp:openobject-addons/5.0. К счастью, в push есть опция --stacked-on, так что вы можете использовать bzr push --stacked-on lp:openobject-addons/5.0 lp:~donkirkby/openobject-addons/feature-x. Также вы можете использовать URL-адреса в стиле lp:, они короче. - person bialix; 29.01.2010
comment
@bialix, я буду придерживаться команды ветвления, потому что она кажется мне более интуитивной. (Возможно, я все еще страдаю от предвзятости Subversion.) Что касается протокола lp:, я начал использовать bzr+ssh: после того, как получил несколько ошибок с lp:, но теперь он работает нормально. Может быть, я не позвонил lp-login или что-то в этом роде. В любом случае, я преобразовал пошаговое руководство, чтобы использовать более короткие URL-адреса. - person Don Kirkby; 02.02.2010
comment
@ Дон, branch в порядке. Я думаю, вам нужно принять свой собственный ответ, потому что он выглядит как очень хорошая и краткая инструкция. - person bialix; 02.02.2010
comment
Я обнаружил ошибку при объединении веток функций. Если они были ответвлениями официальной ветки после того, как вы в последний раз обновили стабильную ветку, то они могут принести дополнительные изменения, когда вы объедините их в свою стабильную ветку. Самое простое исправление — выполнить слияние из официальной ветки перед слиянием с функциональной веткой. Я поэкспериментирую с осью предок: ревизия, а затем обновлю пост. - person Don Kirkby; 11.02.2010

Такая политика (с использованием предложений по слиянию или исправлений) должна определяться основными разработчиками или сопровождающими самого проекта. Но, как правило, использование отдельных веток для каждого исправления предпочтительнее, чем просто патчи.

  • Потому что обычные патчи могут устаревать по мере развития магистральных веток. Когда вы сохраняете ветку для исправления, вы можете обновить свое исправление в соответствии с последними изменениями в стволе.
  • Исправления в ветвях легче анализировать, потому что другие разработчики могут видеть все ваши промежуточные шаги по устранению проблемы или то, как ваше исправление развивалось с течением времени по мере изменения ствола.
  • Кроме того, исправления, прикрепленные к сообщениям об ошибках, часто пропускаются или забываются. В то время как список всех активных предложений по слиянию отображается на странице «Ветви» каждого проекта.
  • Объединение вашего исправления из вашей ветки означает, что история (и аннотации) сохранит ваше имя как автора пути, а не основного разработчика, который применил ваш патч.

Хранить все исправления в одной ветке нехорошо для использования в предложении по слиянию. Но это полезно само по себе для тестирования всех ваших исправлений или использования его в качестве стабильной ветки (например, для тестирования). Поэтому я предлагаю использовать отдельные ветки (функции) для каждого отдельного исправления, создавать для них отдельные предложения по слиянию и объединять эти ветки в вашу стабильную ветку, как вы делаете сегодня. Таким образом, вы можете получить полную свободу в применении дополнительных изменений к каждому вашему исправлению, а затем снова объединить его со своей стабильной веткой.

Если вам нужно разделить существующую стабильную ветку на несколько отдельных веток, вы можете воспользоваться рецептом Джона Мейнеля, описанным в его блоге: http://jam-bazaar.blogspot.com/2009/10/refactoring-work-for-review-and-keep.html

person bialix    schedule 23.01.2010
comment
Спасибо, это полезно. Не могли бы вы прояснить пару вещей? В блоге Джона он предлагает запустить bzr branch --switch ../dogpile ../feature1 для создания новой ветки. Эта ветвь feature1 локальна для моей машины или размещена на панели запуска? Чтобы предложить ветку для слияния, она должна быть размещена на панели запуска, верно? - person Don Kirkby; 26.01.2010
comment
И dogpile, и feature1 являются локальными ветвями (в локальном общем репозитории). Вы работаете локально, пока не будете готовы подать предложение о слиянии. Затем вы отправляете свою ветку на LP: bzr push lp:~your-name/project-name/branch-name. Затем откройте страницу ветки командой: bzr lp-open и предложением слияния файлов. - person bialix; 26.01.2010
comment
Спасибо за помощь. Теперь я опубликовал сводку полного рабочего процесса, который я использую на основе ваших предложений. - person Don Kirkby; 29.01.2010