BZR : а какая разница между commit и push?, ну и соответственно между update/merge/pull? Опции

[yes]

а то что-то не сложилось понимания...

я на простейшем примере попробовал - вроде как работает, но непонятно разница между различными методами workflows в user guide кажется надуманной, то есть разницы в использовании инструмента я не понял

то что попробовал скорее всего соответствует Centralized with local commits, но из-за того, что не понял отличий - не уверен

-----------

ну и до кучи - центральный репазиторий, как я понял, понятие условное и в любой момент любой локальный можно "переименовать" в центральный, так?
рассматривая простейший случай - все URL типа file: и никаких --no-tree

[Harbour]

юзаю git, но думаю термины те же.

commit - записывает изменения кода в локальный repo, с логом или без (в случае changeset'а)
push - синхронизирует remote repo с local one
update - х.з. нет такого понятия в git (базар всегда отличался какими-то дикими определениями)
pull - синхронизирует local repo с remote one
merge - работа с ветками, тут обычно применяется merge стратегия (resolve/recursive/octopus/ours/subtree) или свои скрипты под задачу

[bialix]

юзаю git, но думаю термины те же.

В чем-то похоже, в чем-то отличается. Так что думаете вы не совсем правильно.

commit - записывает изменения кода в локальный repo, с логом или без (в случае changeset'а)
push - синхронизирует remote repo с local one
update - х.з. нет такого понятия в git (базар всегда отличался какими-то дикими определениями)

Полегче на поворотах, уважаемый. Вы cvs/svn никогда не пользовались?
А какой командой в гите вы обновляете рабочую копию после pull?

а то что-то не сложилось понимания...

Печальное зрелище.

я на простейшем примере попробовал - вроде как работает, но непонятно разница между различными методами workflows в user guide кажется надуманной, то есть разницы в использовании инструмента я не понял

А вы и не заморачивайтесь поначалу. Работайте по самому простому сценарию.

то что попробовал скорее всего соответствует Centralized with local commits, но из-за того, что не понял отличий - не уверен

Я не знаю, что вы конкретно пробовали и что хотели достичь. Попробуйте поточнее сформулировать вопрос.

ну и до кучи - центральный репазиторий, как я понял, понятие условное и в любой момент любой локальный можно "переименовать" в центральный, так?
рассматривая простейший случай - все URL типа file: и никаких --no-tree

1) Не "переименовать".
2) Да, любой репозиторий может быть как центральным (мастером), так и подчиненным.

commit = фиксация локальных изменений в ветке в виде новой ревизии. Фактически запись истории. Полный аналог svn commit.

push = отправка новых ревизий из своей рабочей локальной ветки в любую другую.

Предлагаю ознакомиться с глоссарием: http://groups.google.com/group/ru_bzr/web/...%80%D0%B8%D0%B9

pull делается когда у вас две ветки не связаны по принципу master-checkout;

update как раз наоборот для связанных веток;

merge для объединения истории двух веток.

[yes]

1) Не "переименовать".
2) Да, любой репозиторий может быть как центральным (мастером), так и подчиненным.

"переименовать" я подразумевал bind,
то есть структура .bzr одинакова?

могу ли я ее скопировать (на usb флаш) и потом "синхронизовать" с другим репозиторием или создать новые WC?
или это недостаточно и нужна еще рабочакя копия?

commit = фиксация локальных изменений в ветке в виде новой ревизии. Фактически запись истории. Полный аналог svn commit.

push = отправка новых ревизий из своей рабочей локальной ветки в любую другую.

ну то есть выполнив commit с явным указанием destination, я получу push?
или push это commit + checkout в новую рабочую копию?

Предлагаю ознакомиться с глоссарием: http://groups.google.com/group/ru_bzr/web/...%80%D0%B8%D0%B9

смотрел, мое мнение - правильное определение терминов вещь нужная, но мне тяжело усваивать, если скрыт/непонятен смысл

pull делается когда у вас две ветки не связаны по принципу master-checkout;

update как раз наоборот для связанных веток;

merge для объединения истории двух веток.

ну если это взаимозаменяемо - то можно си сопоставить : то есть
merge == update + commit
pull == ...

они же все (по моим опытам) работают с рабочей копией, где предлагают слить/исправить конфликты, после этого можно заливать в репозиторий

---------------------

вопросы к тому - являются ли эти группы комманд взаимозаменяемыми (ну то есть не совсем синонимы типа checkin commit), а одна команда с разными опциями позволяет сделать то же что другая или же одна комманда является групповой командой - то есть может быть заменена последовательностью других комманд (например как hg fetch)?

если не сложно, объясните это. все-таки документация не очень подробна...

--------------------

и до кучи - конкретный вопрос: что можно сделать с виндовзным CR+LF? чтобы unix-windows тексты не глючили?

пользовались, только в отличие от bzr там нет двусмысленных комманд
хе, это что там еще надо в git'е после pull обновлять ? еще раз повторюсь - много лишних действий - это bzr, одно конкретное ясное и понятное действие - это git.

ну я тоже склоняюсь в сторону git-а, все-таки гораздо более проработанный проект на текущий момент.

та же авто конверсия CR-LF в CR - мелочь, а приятно, что хуки никакие писать не надо...

во вторых скорость - даже на моих (весьма маленьких) проектах при работе с файлами (репозиторий там же, где и WC) bzr существенно тормозит

----------------

hg еще смотрю - там плюс, имхо, книжка в "свободном" стиле, в которой автор объясняет что к чему

----------------

[bialix]

ну я тоже склоняюсь в сторону git-а, все-таки гораздо более проработанный проект на текущий момент.

Вы полезли в глубокие дебри bzr не разобравшись в основах. Вот совсем свежая статья, которая рассматривает основы: http://hlabs.spb.ru/development/versions/bazaar.html

Или... А может ну его этот дурацкий базар, если гит вам кажется более проработанным?
Под виндой тока гит не запускайте, и будет вам щастье.

во вторых скорость - даже на моих (весьма маленьких) проектах при работе с файлами (репозиторий там же, где и WC) bzr существенно тормозит

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

пользовались, только в отличие от bzr там нет двусмысленных комманд
хе, это что там еще надо в git'е после pull обновлять ? еще раз повторюсь - много лишних действий - это bzr, одно конкретное ясное и понятное действие - это git.

Не поленился посмотреть в ман на гит.
Команда pull внутри вызывает команду fetch, которая подтягивает ревизии, а затем делает merge с локальной рабочей копией. Либо может сделать rebase при использовании соответствующего ключика.

Может вам будет интересно, что в hg команда pull делает только fetch, а затем нужно принудительно обновлять рабочую копию командой update (О ужас! опять эта дурацкая команда!)

В bzr команда pull работает также как в гите.

Почти в тему: вопросы знатокам BZR.

Боюсь, что знаток я здесь один в единственном числе.

Мне в BZR очень нравится, что переименования реализованы как положено. Mark Shuttleworth в своём блоге приводит убедительные аргументы в пользу Bazaar.

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

Хочется пользоваться, но есть вопросы...

1) Можно ли доверять этому зверю? Учитывая, что они уже несколько раз формат хранилица меняли, возникает опасение: с таким непостоянством нет ли у них багов, портящих данные?

О каком непостоянстве речь? У базара имеется полная обратная совместимость со всеми прошлыми форматами репозитория вплоть до 2006 года. Хоть эти смены форматов и выглядят как хаос, но если пользоваться только форматом по умолчанию, который уже не менялся 1 год, то вас как пользователя эти вопросы не должны мучать в принципе. Все, повторяю еще раз ВСЕ форматы постоянно тестируются автоматической системой тестов, количество тестов на сегодняшний день превышает 15000, еще раз буквами: пятнадцать тысяч. Данные в репозитории не портятся, этому можно доверять. Однако это не отменяет необходимость делать периодические бэкапы. При использовании любой системы контроля версий.

2) Какие перспективы у TortoiseBZR? Я устанавливал релиз 1.09. TortoiseBZR произвёл впечатление весьма сырого продукта. Можно ли рассчитывать на то, что через командную строку работает надёжнее?

Командная строка ЕСТЕСТВЕННО работает надежнее, потому что она была и есть с самого начала проекта. Я пользуюсь базаром в командной строке с 2005 года. На винде. FAR рулит.

Для винды рекомендую использовать плагин QBzr в качестве комбинированного подхода: команды все равно запускаются из командной строки, но весь интерфейс графический. Кстати этот же самый интерфейс использует и TortoiseBzr :-) Плагин QBzr включается в стандартную поставку для винды (если вы используете standalone installer).

--------------------------------

Попробую все-таки ответить на вопросы yes.

"переименовать" я подразумевал bind,
то есть структура .bzr одинакова?

Да.

могу ли я ее скопировать (на usb флаш) и потом "синхронизовать" с другим репозиторием или создать новые WC?

Можете.

или это недостаточно и нужна еще рабочакя копия?

Не нужна. Рабочая копия -- это для работы, вся история самодостаточна.

ну то есть выполнив commit с явным указанием destination, я получу push?

Нет. commit == создание новой ревизии в локальном репозитории, push == пересылание имеющихся ревизий между двумя репозиториями.

merge == update + commit

Нет, merge не делает commit. Фиксацию после merge нужно делать самому.

вопросы к тому - являются ли эти группы комманд взаимозаменяемыми (ну то есть не совсем синонимы типа checkin commit), а одна команда с разными опциями позволяет сделать то же что другая или же одна комманда является групповой командой - то есть может быть заменена последовательностью других комманд (например как hg fetch)?

если не сложно, объясните это. все-таки документация не очень подробна...

Я не понимаю, что именно вам объяснять. Может начать с азов?

Создать новую ветку локально:

bzr init

В текущем каталоге будет инициализировано новое рабочее пространство и появится каталог .bzr для хранения внутренней информации.

Создаете/копируете файлы в рабочий каталог. Их нужно добавить, что bzr знал о их существовании и отслеживал изменения в файлах:

bzr add

Затем вы наверное захотите сохранить текущее состояние файлов в виде новой ревизии:

bzr commit

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

bzr status
bzr diff

Как только будете готовы, снова фиксируете:

bzr commit

Чтобы просмотреть историю фиксаций:

bzr log

В какой-то момент вы захотите опубликовать свою ветку или просто скопировать ее на сервер/ USB-флеш/ на соседнюю машинку по сетке. Вот тут вам и пригодится команда bzr push, она создат (если надо) новую ветку в месте назначения и скопирует туда всю историю вашей ветки, т.е. все ревизии. После push вы получаете фактически копию своей ветки, но чаще всего без рабочей копии. В случае локального push -- т.е. на другой диск на той же машинке -- рабочая копия будет восстановлена автоматически. Иначе чтобы воссоздать рабочую копию делаете:

bzr checkout

Чтобы сделать копию ветки локально (например, чтобы попробовать написать какой-то новый код, октором вы не уверены, что сразу получится) делаете

bzr branch

Опять же будет создана копия вашей ветки, чаще всего уже с рабочими файлами. Эти две ветки связане некоторым родством (потому что имеют общую историю). Далее, чтобы между ними обмениваться ревизиями, можно использовать pull/push/merge

pull = вытягивает историю из другой ветки и копирует ее в текущую рабочую ветку
push = наоборот: передает ревизии из текущей рабочей ветки в другую ветку
merge = объединяет ревизии из другой ветки в вашу текущую рабочую ветку и пытается объединить изменения в файлах. Если возникают конфликты, то создаются специальные файлы THIS/BASE/OTHER. Конфликты нужно порешать (отредактировать файлы), затем сделать bzr resolve
Когда вы будете удовлетворены состоянием ветки после merge нужно зафикисировать опять же командой bzr commit.