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.

[yes]

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

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

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

1) сделать diff с одной ветки patch на другую (cvs/svn фунции) - это вроде работает

2) поддержание нескольких синхронных репозитариев с минимальным геммороем при слиянии, при этом, какой из них главный - не важно и может меняться со временем

внутренняя кухня меня интересует мало, так же как, например, не интересуют алгоритмы по которым make зависимости находит

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

да вроде бы заработало. меня cygwin и vi, которые ставит win-git не пугают как-то
я понимаю, что есть люди, которые от vi могут офигеть и нужно было бы другой редактор под винду ставить
ну и нету интеграции в эксплорер - мне это нафиг и не надо (а вот CRLF трансляция - очень в тему)
какой-то графический вьювер "репозитария" есть (git-gui)

какие проблемы от git-а под виндой нужно ожидать? (это не риторический вопрос)

я сейчас пытаюсь некий компаризон для себя сделать, начал с bzr, для git / hg проделал только туториал
поэтому возможно разочарование git-ом наступит позже

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

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

то же залил в git и hg, но пока не сливал/курочил

с секундомером не мерил - субъективное впечатление, но могу time для unix-а пустить

для проекта реального (где-то поллимона строк cvs (cvs+ssh) очень не быстро работало - десятки минут update, для svn приблизительно минут 10 было - без истории) - вобщем терпимо, но если при прочих равных git будет делать это за минуту - однозначно плюс

повторяю еще раз ВСЕ форматы постоянно тестируются автоматической системой тестов, количество тестов на сегодняшний день превышает 15000, еще раз буквами: пятнадцать тысяч. Данные в репозитории не портятся, этому можно доверять. Однако это не отменяет необходимость делать периодические бэкапы. При использовании любой системы контроля версий.
Командная строка ЕСТЕСТВЕННО работает надежнее, потому что она была и есть с самого начала проекта. Я пользуюсь базаром в командной строке с 2005 года. На винде. FAR рулит.

к надежности лично у меня мало подозрений. этот аспект наверняка одинаково хорош у всех трех систем.
вопрос в дополнительных мелочах

ну и как-то странно - если графический тул является просто оболочкой (а не полностью пересобраным как в tortousesvn), то его надежность приближается к командной строке.
я xemacs-овской модой для cvs|svn пользуюсь - ну заглючило - прибил буфер, ни репозиторию, ни рабочей копии от этого ничего плохого не делается

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

QBzr - спасибо, фиг бы догадался
его только как команду, типа bzr qbrowse пускать или есть какой-то другой путь?

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

большое спасибо.
собственно, если бы не Ваше участие в этом форуме, я бы bzr не стал бы смотреть

но позволю проявить назойливость

повторять туториал с сайта - нет смысла
обяснять функции VCS c единым репазитарием, тоже не надо, cvs-ом пользовался лет ~10, svn вроде бы без принципиальных вопросов - пол-года

внутренности системы - мне тоже не очень интересны, хотя если без этого не понять - буду благодарен за объяснения

собственно интересно - зачем нужны push и pull

как я понял (и сумел осуществить) для синхронизации репозитозитариев (вернее веток - по терминологии доки, хотя ветки могут жить и в одном репозитарии)
достаточно update-commit-merge

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

ну а если я скопирую средствами ОС - то есть просто скопирую .bzr
какая разница?

bzr branch

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

я так понял, что bzr branch аналог svn copy или cvs tag -b
то есть противоречие с предыдущей цитатой - push/pull не просто копируют ветки, а должны использовать слияние (а merge в свою очередь использует update чтобы конфликты поубирать)

pull = вытягивает историю из другой ветки и копирует ее в текущую рабочую ветку
push = наоборот: передает ревизии из текущей рабочей ветки в другую ветку

ну так история в destination затирается или нет?

я сумел обойтись update/commit/merge для синхронизации нескольких репозитариев - что я делал не так?