Представить исправления ошибок на launchpad через предложения по слиянию или участки?
Я плохо знаком с Launchpad и Bazaar, и я пытаюсь выяснить то, что лучший способ состоит в том, чтобы представить исправления ошибок. Я использую некоторое довольно популярное общедоступное программное обеспечение, это принято на Launchpad, но это не очень стабильно. Я создал свою собственную ветвь проекта стабилизировать его и применить просто исправления ошибок, в которых мы нуждаемся, не добавляя другие изменения от продолжающегося развития.
Когда я регистрирую ошибки и затем выясняю, как зафиксировать их сам, я выдвигаю фиксацию к нашей стабильной ветви. Как я должен издать фиксацию назад к главному проекту? Я мог создать файл участка и приложить его к ошибке, или я мог предложить слияние для нашей стабильной ветви.
Если я исправляю несколько ошибок, я могу внести отдельное предложение по слиянию по каждому, или действительно ли они совокупные?
2 ответа
У меня достаточно тяжелое программирование в пути на ноутбуке (читать: не нетбук) просто потому, что у меня есть только один экран. Вы говорите мне, что кто-то рассмотрел бы программирование на этом использовании виртуальной клавиатуры, которая поднимает половину космоса экрана?
iCantBelieveYouAskedThis
-121--1465621- Это связано с включением опции 'esckeys' (следствием несовместимого , как я только что обнаружил). При нажатии ^ [ O происходит небольшая задержка, так как выясняется, используете ли вы клавишу со стрелкой/функцией или вы просто подразумевали эти две клавиши в последовательности.
Одним из решений является отключение этой опции и отказ от клавиш со стрелками в режиме вставки.
Другое - установить 'timeoutlen' на что-то меньшее, чем 1000, может быть, 100 (но будьте осторожны при медленных соединениях).
Другим способом является использование ^ C вместо ^ [ для выхода из режима вставки.
Обновление: Похоже, официальная документация проекта 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 сообщает базару, какое имя учетной записи использовать на сайте launchpad, а команда whoami сообщает базару, какое имя использовать для каждой зафиксированной версии. Адрес электронной почты, используемый в whoami , должен совпадать с одним из адресов электронной почты, настроенных для учетной записи Launchpad.
cd ~/workspace/openobject-addons/feature-x
bzr lp-login donkirkby
bzr whoami "Don Kirkby <donkirkby@example.com>"
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 создаст для него разницу. Это стоит того, чтобы пересмотреть эту разницу.Иногда я выбрал не ту ветвь в качестве цели, и я заметил только потому, что разница была намного больше изменений, чем я ожидал. Существует также команда 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"
После использования --замечания при слиянии из официальной ветви можно просто использовать bzr слияние самостоятельно для слияния из официальной ветви. Если проект использует тэги для обозначения точек освобождения, можно просмотреть список тэгов и объединить их из тэга.
cd ~/workspace/openobject-addons/main
bzr tags -d lp:~openerp/openobject-addons/5.0/
bzr merge -r tag:5.0.7rc2
Такая политика (с использованием слияния предложений или патчей) должна быть определена основными разработчиками или сопровождающими самого проекта. Но в качестве общего правила, используя отдельные ветви для каждого исправления, предпочтительнее способа на простых патчах.
- Поскольку обычные патчи могут устареть, когда развитие ствола ствола движется вперед. Когда вы держите ветку для исправления, вы можете обновить исправление в соответствии с последними изменениями в багажнике.
- Исправления в ветвях проще анализуют, поскольку другие разработчики могут видеть все ваши промежуточные шаги для фиксации проблемы, или как ваше исправление эволюционировало в течение того времени, когда изменился багажник.
- также патчи, прикрепленные к сообщениям об ошибках, часто склонны пропустить или забыты. Хотя список всех активных предложений слияния заметно показан на странице «Филиалов» каждого проекта.
- Объединение вашей фиксации от вашей ветки означает историю (и аннотации) сохранит ваше имя как автор PATH, а не основной разработчиков, который применил ваш патч.
Держите все исправления в одной ветве не очень хороши для использования в предложении слияния. Но это полезно для тестирования всех ваших исправлений или использование его в качестве стабильной ветви (например, для собачьих продуктов). Поэтому я предлагаю использовать отдельные (функциональные) филиалы для каждого отдельного исправления, файла для них отдельные предложения объединения и объединяют эти ветви в вашу стабильную ветку, как вы делаете сегодня. Таким образом, вы можете получить полную свободу превышения применения дополнительных изменений в каждое исправление, а затем снова объединить его в свою стабильную ветку.
Если вам нужно разделить существующую стабильную ветвь на несколько отдельных ветвей, вы можете использовать рецепт от Джона Мейнеля, описанного в своем блоге: http://jam-bazaar.blogspot.com/2009/10/refactoring- Работа - для обзора и-and-storm.html