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

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

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

-----------

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

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

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

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



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




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



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



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



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

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

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

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

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

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

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

пользовались, только в отличие от bzr там нет двусмысленных комманд



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

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

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



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



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



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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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



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




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

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

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




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



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



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



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

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

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

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


Да.


Можете.


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


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


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



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

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

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.

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

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

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 будет делать это за минуту - однозначно плюс



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

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




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




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

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

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

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

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

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




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



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



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

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

Ув. bialix, спасибо за разъяснения. Более конкретный вопрос:
Предположим, я хочу использовать систему контроля версий для работы с "двоичными" файлами (например, AutoCAD, P-CAD и прочие CADы). Я хочу иметь возможность более-менее свободно переименовывать файлы и директории в хранилище, при этом не увеличивая размер хранилища. Простой тест с Hg (хранилище из 1 файла, чистая история) показал, что при переименовании файла размер хранилища увеличился в 2 раза. Страшно себе представить, что будет, если переименовать директорию на 300 Мбайт. Такая же операция в SVN не увеличила существенно размер хранилища (cheap copy). По слухам, BZR тоже должен не ударить в грязь лицом. Правильный ли я делаю вывод, что при таком сценарии использования BZR выигрывает у Hg по экономии дискового пространства?

Да, правильный вывод. Hg делает переименование как две операции: copy+delete, поэтому после переименования история дублируется (как результат операции copy). Хотя это обещают исправить, так что может быть в ближайшие 6-12 месяцев этьот недостаток действительно устранят.

Базар отслеживает файлы по уникальным идентификаторам (грубо: аналог inode в линуксовой файловой системе). Поэтому при переименовании файла идентификатор и его история не меняется, меняется только текущее имя файла. Всё.



К сожалению, просто переносить свой опыт из CVS/SVN напрямую в Базар нельзя. Потому что у них разная внутренняя модель, тот базовый стержень вокруг которого все крутится. Я говорю не о технической реализации репозитория, а именно о наборе базовых идей, на основе которых построена вся реализация Базара. У Гита своя модель, у Меркуриала своя. Где-то они имеют общие точки соприкосновения, где-то нет.

Вот например команда pull.

В SVN такой команды нет, ближайший аналог svn update, в результате рабочая копия будет обновлена.

В Hg эта команда просто копирует ревизии из одного репозитория в другой и не обновляет рабочую копию. После pull обычно надо сделать или update или merge.

В Git команда pull -- это на самом деле 2 разные команды, выполняемые паравозиком: fetch (копирует ревизии из одного репозитория в другой) и затем merge или rebase в зависимости от ключика командной строки. Если две ветки разошлись, то они будут объединены.

В Bzr pull копирует новые ревизии, но только в том случае если ветки не разошлись, т.е. локальная ветка является родителем для другой ветки, и все новые ревизии спокойно ложатся как продолжение истории (без merge). Это соответствует fast-forward merge в терминах Git.

Видите? Простой термин, pull в переводе на русский -- это "вытянуть", "вытащить", "высосать" -- а во всех 3 системах она работает чуточку по разному. Да?

Плюс еще путаница в терминологии.

В hg и git репозиторий -- это главное понятие, а ветка она как бы виртуальная внутри репозитория.

В bzr существуют 3 отдельных понятия: репозиторий как хранилище ревизий; ветка, как конкретная история проекта; рабочая копия, как собственно файлы, с которыми вы работаете. Причем они могут присутствовать все одновременно, или некоторые части могут отсутствовать.



Это зависит от желаемого сценария работы. Вы хотите svn-like с checkout?



А зачем diff+patch? Для этого есть merge.



Я не понимаю этой фразы. Минимальный геморрой при объединении как бы гарантирует любая распределенная система, потому что merge -- это одна из базовых команд.



Проблемы с русскими буквами в комментариям к фиксациям + проблемы с русскими именами файлов. Совсем недавно ставил msysgit и в очередной раз понял, что моим требованиям он не удовлетворяет.



Вы ставили bzr из готового пакета? У bzr объективно время старта долгое 100-200 мс, частично из-за того, что система на питоне писана. Так что объективные цифры (time) был бы интересен. Хотя объективно и субъективно все равно он будет чуток медленнее git и hg.



Под Линукс с Gnome возможно будет интереснее использовать плагин bzr-gtk.



Пока только как команды: qbrowse, qlog, qcommit, qdiff и проч.



Еще раз повторюсь. Переносить напрямую свой опыт из CVS/SVN в распределенные системы (любые!) -- будет огромной ошибкой. Не считайте себя супер спецом только потому что вы уже 10 лет работали с CVS. Некоторые вещи придется переучивать и ломать стереотипы.



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



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



Для централизованного стиля работы:

есть "главная" ветка на условном сервере. по терминологии она зовется master branch

Чтобы начать работу локально:

bzr checkout URL

Будет создана локальная рабочая копия с историей, "привязанная" к серверу (bound branch)

Поработали. status, diff, commit
При commit новая ревизия автоматом уходит в главную ветку и в локальную ветку, обе ветки таким образом засинхронизированы.

Если кто-то другой (ваш коллега по работе) уже успел сделать commit в главную ветку до вас, то вам нужно синхронизировать локальную ветку с главной. Для этого используется команда update.

После update вы можете делать commit.

Собственно базовый набор команд. Радикально не отличается от svn, и даже push/pull в таком сценарии обычно не используется. Push/pull -- это прежде всего для синхронизации двух независимых веток.



Разница небольшая, но она есть. Но в принципе копирование средствами ОС -- это вполне легальная операция.



Приблизительно, да.



Нет, нет и нет.



Если у вас централизованная схема работы -- все так, смотри выше.

еще раз спасибо, но поробую спросить еще раз

как централизованную VCS использовать bzr мне смысла нет, svn (да и cvs) вполне достаточно

я хочу иметь возможность работать с локальными репозиториямии, содержащими по нескольку веток (здесь это branch cvs или ветка svn, что такое ветка распределенной системы (bzr) я четко не понял)

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

внутри каждого локального репозитория система должна обеспечивать те же функции, что и cvs | svn, (то есть пока "центральный" репозиторий недоступен)

пример svn команды -
svn merge -r 75:HEAD \ svn+ssh://syemets@fulcrum/var/local/group/systech/svn/triumph40n/trunk/rtl/top/core/shared_mem

то есть исполнив такую команду в WC бранча (в этом конкретном случае для специфического симулятора - все файлы имеют некое отличие от trunk-а), я применю к WC исправления сделаные с 75 по HEAD c основной ветки (trunk)
75 ревизия - это момент, когда разошлись ветки (была сделана svn copy)

собственно вопрос - обладает ли bzr какой-либо дополнительной функциональностью для таких действий? (ну, например, за счет того, что он помнит слияния)

-----------

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

в конкретном примере - я сделал один "центральный" репозитарий и два локальных (сделаных через bzr branch).
выполняя изменения в каждом из локальных отдельно, затем выполнял bind [вначале одну локальную "ветку", затем другую, после этого update первой и unbind обоих] к центральному и синхронизировал с ним ( update -> merge)
в результате видел, что в рабочих копиях, привязаных к локальным репозиториям, файл синхронизовался (то есть сливались изменения сделаные в обоих локальных)

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


===========

btw: у git-f под линуксом дофига всяческих "расширителей" интерфейса cogito, repo и т.п. - ими кто-нибудь пользуется?

попробовал то же с push / pull - опять нифига не понял
хоть и bzr info сообщает parent branch, но этим командам все равно нужно аргумент (делал копи-паст с вывода bzr info)

иногда pull сам все делает (создает конфликт), а иногда требует запуска merge

применять push / pull можно не только к родительской ветке, но и к "братским" веткам

вобсчем действительно, что-то слишком сложно - возьму пока паузу.

---------------
проект
1716467 lines
2428 files
73964254 bytes

time

bzr commit (первый после init, add)
real 0m21.453s
user 0m15.629s
sys 0m0.628s

bzr branch
real 0m10.856s
user 0m9.393s
sys 0m1.160s

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

git commit
real 0m0.762s
user 0m0.624s
sys 0m0.084s

cit clone !!! - такое впечатление, что cp медленней
real 0m0.804s
user 0m0.336s
sys 0m0.288s

=======================

но как мне кажется, для честного сравнения нужно бы в bzr использовать какие-нибудь no-tree и lightweight-checkout, но сомневаюсь, что на порядок убыстрицца

Проект на 73 метра??? И это все текстовые файлы или там есть и бинарные? Сравнение git commit нечестное, потому что надо учесть, что git add делает "предкоммит". В остальном -- я скорее согласен с этими цифрами, чем нет. 73 метра -- это 73 метра. bzr сосет на проектах больше 20 метров.

Ну и до кучи: что за система у вас (версия Линукса, размер оперативной памяти, частота проца, файловая система?). bzr ставили из пакетов или руками?



Нет, использовать bind+update в такой схеме не правильно. Вместо bind+update вы должны запускать команду pull. Если ветки разошлись (branches are diverged) нужно делать merge.

:btw: у git-f под линуксом дофига всяческих "расширителей" интерфейса cogito, :repo и т.п. - ими кто-нибудь пользуется?

хмм... ну типа упрощенные интерфейсы иногда сугубо "под задачу" - мне лично проще в makefile соответсвующий rule прописать из команд самого git. Красиво выглядят web'овские надстройки, хотя тоже на любителя, так как по большому счету реально в жизни нужно что-то типа redmine

Как я понял, cogito - это способ "облагородить" интерфейс git во времена, когда git требовал внешний скрипт для любого действия. Сейчас git "подрос" и стал более удобоваримым сам по себе. Следовательно, отпала надобность в cogito. Собственно, так тут и написано:
Cogito home page

Создатель Cogito сегодня является официальным maintainer git. Если уж искать чего-то, то имеет смысл смотреть в сторону GUI, типа QtGit и проч.

До кучи: http://whygitisbetterthanx.com/, нажимать Expand All

http://lib.custis.ru/index.php/Линус_Торва...на_Google_Talks - русский перевод прикольного доклада создателя Git