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

Я пользовался им три месяца (мы перешли на меркуриал, pure win) и теперь имею все основания заявить, что базар - плох. Как по фичам, так и по интерфейсу. Как снаружи, так и внутри. И тут будут перечислены те моменты, которые я считаю глупыми, неудачными, неадекватными и т.п. Это не сравнение базара с нормальной системой контроля версий, это не спор с кем-либо - это просто перечисление проблем, чтоб в следующий раз кто-то, кто будет посматривать на базар, возможно напоролся на эту статью и сказал - "нет-нет-нет, Девид Блейн, такой магии нам не надо".

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

piranha@gto ~/dev/work/trunk> bzr slog -l 3
873: Coder 2011-01-19 * Applied some patch
872: GK 2011-01-19 [merge] Merged release
871: Gk 2011-01-19 [merge] Merged release

piranha@gto ~/dev/work/trunk> bzr slog -l 3 -n0
873: Coder 2011-01-19 * Applied some patch
1776: GK 2011-01-19 [merge] Merged release
  1644.81.11: GK 2011-01-19 [merge] Merged old release

piranha@gto ~> bzr help branch | grep Aliases
Aliases:  get, clone

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

Я пользовался им три месяца (мы перешли на меркуриал, pure win) и теперь имею все основания заявить, что базар - плох. Как по фичам, так и по интерфейсу. Как снаружи, так и внутри. И тут будут перечислены те моменты, которые я считаю глупыми, неудачными, неадекватными и т.п. Это не сравнение базара с нормальной системой контроля версий, это не спор с кем-либо - это просто перечисление проблем, чтоб в следующий раз кто-то, кто будет посматривать на базар, возможно напоролся на эту статью и сказал - "нет-нет-нет, Девид Блейн, такой магии нам не надо".

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

piranha@gto ~/dev/work/trunk> bzr slog -l 3
873: Coder 2011-01-19 * Applied some patch
872: GK 2011-01-19 [merge] Merged release
871: Gk 2011-01-19 [merge] Merged release

piranha@gto ~/dev/work/trunk> bzr slog -l 3 -n0
873: Coder 2011-01-19 * Applied some patch
1776: GK 2011-01-19 [merge] Merged release
  1644.81.11: GK 2011-01-19 [merge] Merged old release

piranha@gto ~> bzr help branch | grep Aliases
Aliases:  get, clone

Хочу похвастаться — вышел Меркуриал 1.4.1, замечательный тем, что в него включили моë расширение — schemes. Это аналог алиасов, но только для адресов. После его включения и добавления в ~/.hgrc таких строчек:

[schemes]
p = ssh://piranha.org.ua/hg/

можно писать hg push p://byteflow/ вместо полного адреса. В расширении уже есть предопределëнные ссылки:

py = http://hg.python.org/
bb = https://bitbucket.org/
bb+ssh = ssh://hg@bitbucket.org/
gcode = https://{1}.googlecode.com/hg/

{1} в gcode означает, что первая часть урла (если считать их так: gcode://первая/вторая/етц/) будет вставлена в начало адреса, а не в конец.

Остальные изменения — в основном мелкие фиксы для 1.4 (который, кстати, вышел две недели назад).

Хочу похвастаться - вышел Меркуриал 1.4.1, замечательный тем, что в него включили моë расширение - schemes. Это аналог алиасов, но только для адресов. После его включения и добавления в ~/.hgrc таких строчек:

[schemes]
p = ssh://piranha.org.ua/hg/

можно писать hg push p://byteflow/ вместо полного адреса. В расширении уже есть предопределëнные ссылки:

py = http://hg.python.org/
bb = https://bitbucket.org/
bb+ssh = ssh://hg@bitbucket.org/
gcode = https://{1}.googlecode.com/hg/

{1} в gcode означает, что первая часть урла (если считать их так: gcode://первая/вторая/етц/) будет вставлена в начало адреса, а не в конец.

Остальные изменения - в основном мелкие фиксы для 1.4 (который, кстати, вышел две недели назад).

Гвидо сегодня анонсировал, что питон переходит на меркуриал. Отлично! ;)

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

Гвидо сегодня анонсировал, что питон переходит на меркуриал. Отлично! ;)

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

NOTE: Not to be confused with a mercurial extension, named shelve.

Few days ago there was a lot links on the Internet to gitshelve, which implements persistent versioned storage of objects in the git. I've read it description and realized that there are few serious design flaws:

• Can store only strings
• Uses subprocess.PIPE for interconnection with git
• Uses bunch of C+Perl+Shell code in Python library instead of using another Python library ;-)

History

We've discussed it with Pythy, and I've convinced him to write hgshelve, which should be easy and pain-free to implement. First thing which we came to is storage of objects through usage of simplejson, which generates (opposing to pickle) easy-readable string representation of objects. Plus objects, dumped by simplejson, can be edited by hands without fear of occasional corruption caused by newline or space.

While I was theorizing, he just wrote code and got hgshelve working. ;-) And from starts all mentioned flaws of gitshelve was fixed. ;-)

Usage

It's really simple to use, just as usual shelve:

>>> import hgshelve
>>> data = hgshelve.open('path/to/repo') # repository is opened/created here
>>> data['key'] = {1: "Hello, world!", 'b': 'just test'}
>>> data.sync()
>>> data
{'key': {u'1': u'Hello, world!', u'b': u'just test'}}

Additionally you can use data.commit, which optionally accepts two arguments: commit message and key to commit (if you want to commit single key).

There are no support of advanced mercurial features, like branches¹ and named branches, though it can arise lately. get_data method can return data from another revision through getting optional argument called rev, which can be one of: revision number, partial (or full) revision hash, mercurial tag.

Dependecies

There are only two of them:

• Mercurial
• simplejson

Where to get

Just clone repository:

hg clone http://hg.piranha.org.ua/hgshelve/

NOTE: Not to be confused with a mercurial extension, named shelve.

Few days ago there was a lot links on the Internet to gitshelve, which implements persistent versioned storage of objects in the git. I've read it description and realized that there are few serious design flaws:

• Can store only strings
• Uses subprocess.PIPE for interconnection with git
• Uses bunch of C+Perl+Shell code in Python library instead of using another Python library ;-)

History

We've discussed it with Pythy, and I've convinced him to write hgshelve, which should be easy and pain-free to implement. First thing which we came to is storage of objects through usage of simplejson, which generates (opposing to pickle) easy-readable string representation of objects. Plus objects, dumped by simplejson, can be edited by hands without fear of occasional corruption caused by newline or space.

While I was theorizing, he just wrote code and got hgshelve working. ;-) And from starts all mentioned flaws of gitshelve was fixed. ;-)

Usage

It's really simple to use, just as usual shelve:

>>> import hgshelve
>>> data = hgshelve.open('path/to/repo') # repository is opened/created here
>>> data['key'] = {1: "Hello, world!", 'b': 'just test'}
>>> data.sync()
>>> data
{'key': {u'1': u'Hello, world!', u'b': u'just test'}}

Additionally you can use data.commit, which optionally accepts two arguments: commit message and key to commit (if you want to commit single key).

There are no support of advanced mercurial features, like branches¹ and named branches, though it can arise lately. get_data method can return data from another revision through getting optional argument called rev, which can be one of: revision number, partial (or full) revision hash, mercurial tag.

Dependecies

There are only two of them:

• Mercurial
• simplejson

Where to get

Just clone repository:

hg clone http://hg.piranha.org.ua/hgshelve/

Чисто ради интереса решил привести один маленький забавный факт о размере репозиториев. Есть у нас немаленький проект, при этом чекаут исходников джанговой части из SVN занимает 79 мегов.

При этом этот же проект, переконверченный в меркуриал - рабочая копия и полная её история вместе - занимает 80 мегабайт.

Чисто ради интереса решил привести один маленький забавный факт о размере репозиториев. Есть у нас немаленький проект, при этом чекаут исходников джанговой части из SVN занимает 79 мегов.

При этом этот же проект, переконверченный в меркуриал - рабочая копия и полная её история вместе - занимает 80 мегабайт.

Я уже довольно давно собираюсь написать хоть какое-то примерное сравнение этих двух систем контроля версий - просто потому, что меня это касается довольно прямым образом. Но постоянно не мог собраться - сомнения, как бы начать, достаточно ли я для себя точек сравнения накопил, и так далее... В конце концов решил не тянуть резину в долгий ящик и написать то, что есть. Возможно, если получится мало и спорно, в жарких дискуссиях начнёт просыпаться истина... эээ... это я как-то отвлёкся от темы, приступим к делу. :-)

Итак - два участника. Git - более гиковский (в представлении его создателей и фанов ;), и Mercurial - написанный на питоне. Аргументы абсолютно ортогональные друг другу, но дело в том, что я всегда тяготел к более гиковским программам - однако логично, что я сейчас тяготею к программам, написанным на питоне. :-) Однако оказалось, что гиковость выразилась в довольно неожиданном (как для меня) виде - абсолютно не в виде нестандартного, более мощного, интерфейса, а в виде... Удачное высказывание - грех не процитировать:

dottedmag: UI неконсистентен совсем

Абсолютно неконсистентен. Можно плюнуть на 146 (!) файлов в /usr/bin (из которых больше ста - компилированные бинарники): они, типа, соответствуют никсовой философии "одна утилита для одной задачи" (на мой взгляд, git в общем выполняет очень даже одну задачу - хранение версий моих данных) - это, кстати, собираются вроде в скором будущем поправить. Но самый простой пример - выбивает из колеи. Для меня являлось нормальным создавать клон репозитория удалённо простой командой:

hg clone byteflow ssh://piranha@piranha.org.ua/dev/byteflow

Репозиторий клонирован. Я могу, опять же по ssh, забрать его. Могу настроить web-доступ для него (опять же, если я настроил весь ~/dev/ показывать в веб-морде, и без этого можно обойтись). В git'e... читаем хелп:

<repository>
The (possibly remote) repository to clone from. See the URLS section below for more information on specifying repositories.
<directory>
The name of a new directory to clone into.

Это мелочь. Я могу поставить sshfs (ха, если я не в винде сижу!), и склонировать как будто бы в локальную директорию. Но эти мелочи идут сквозняком через весь интерфейс git'а, что приводит к значительно более раздражающей меня проблеме - адресам у веб-интерфейса. Достаточно сравнить:

• http://git.catap.ru/?p=emacs-jabber.git;a=blob;f=jabber-chatbuffer.el;hb=HEAD
• http://hg.piranha.org.ua/byteflow/file/tip/urls.py

Из обоих убраны идентификаторы ревизии (заменены на символические аналоги последней ревизии - HEAD и tip). Что легче прочитать? Запомнить? Я очень часто набираю ссылки по памяти, но с git'ом этот фокус провернуть на порядки сложнее.

Ещё одна проблема с адресами - у меркуриала один и тот же адрес является адресом веб-интерфейса и адресом для самого клиента меркуриала: надо помнить лишь один адрес. С гитом этот номер не прокатит - попробуй догадайся про адрес у первого репозитория без подсказки? Тут повезло, всего лишь git://git.catap.ru/emacs-jabber. Но... интерфейс, это интерфейс...

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

Продвигаемся вперёд по плану гнобления¹: набор команд. Не видел ни разу человека, набиравшего команду status полностью - все пишут st. Обломитесь - в гите нельзя сокращать команды. Нету автоматических (ну конечно, всегда можно сделать алиасы) st, ci, и вообще никаких сокращений команд - при этом в меркуриале кроме предустановленных сокращений хватает любого набора букв, достаточного для несомненного определения команды.

А что мы можем сказать о помощи? У систем огромное количество команд и возможностей. Помощь в меркуриале - это информация по сути дела. hg help clone - одна страница с описанием поведения при разных условиях и списком специфических опций. git help clone - 4 страницы текста. Зачем мне столько? Я хочу краткий хелп, а не руководство. Руководство должно быть в man-pages или в виде книжки. Когда у меня есть только медленная консоль, это не может не раздражать.

На этом претензии, накопленные не к фичам гита, у меня пока исчёрпываются - можно лишь благодарить богов, что мне не приходится это чудо использовать так же много, как и меркуриал. К фичам придраться тоже можно было бы, но этого и так хватает в интернетах - к примеру, отсутствие удобного аналога mq.

К завершению подойду полупинком (почему "полу" - об этом позже) в сторону меркуриала. В гите есть довольно удобная штука в виде бранчей. Это что-то типа внутрирепозиторийных клонов (можно провести прямую аналогию с директориями trunk и branch, являющихся обычным приёмом при работе с svn). Самый большой прикол заключается в том, что бранчи в полный рост реализованы в меркуриале - но никаким образом не реализована удобная работа с ними:

• hg fetch (который является склеенным скачиванием обновлений и автоматическим их мержем) может поломаться, когда изменения для мержа есть в нескольких ветках.
• tip стоит не на основной ветке, а на последнем коммите.
• hg backout не проверяет, из текущей ли ветки запрашиваемый чейнджсет, или нет.
• hg push определяет создание нескольких "голов²" только для текущей ветки.

Почему это полупинок? По двум причинам:

1. На большинство проблем уже заведены баги, и работа над ними ведётся, хотя это и слабая отмазка. :-)
2. В большинстве случаев использование бранчей неоправданно и их замена обычными клонами (отдельными репозиториями) создаёт куда более прозрачный цикл работы.

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

В принципе, замечания по поводу "это лучше, а это хуже" - приветствуются, особенно личные и субьективные (субьективные не в плане "я щетаю шо субверсион рулед и капец!" ;). Ссылки на статьи... я бы предпочёл пережёванные мысли комментирующих, потому что статей уже сам почитал - пока ни одной вменяемой git vs hg, где гит был лучше, не видел. В основном фанаты какие-то.

P.S. Тут в статье случайно мелькнуло слово svn. Чтоб развеять сомнения в моей ориентации, спешу сообщить - я натурал, svn ненавижу за крайнюю угрёбищность и перманентную порчу последнего года жизни. :-)

Я уже довольно давно собираюсь написать хоть какое-то примерное сравнение этих двух систем контроля версий - просто потому, что меня это касается довольно прямым образом. Но постоянно не мог собраться - сомнения, как бы начать, достаточно ли я для себя точек сравнения накопил, и так далее... В конце концов решил не тянуть резину в долгий ящик и написать то, что есть. Возможно, если получится мало и спорно, в жарких дискуссиях начнёт просыпаться истина... эээ... это я как-то отвлёкся от темы, приступим к делу. :-)

Итак - два участника. Git - более гиковский (в представлении его создателей и фанов ;), и Mercurial - написанный на питоне. Аргументы абсолютно ортогональные друг другу, но дело в том, что я всегда тяготел к более гиковским программам - однако логично, что я сейчас тяготею к программам, написанным на питоне. :-) Однако оказалось, что гиковость выразилась в довольно неожиданном (как для меня) виде - абсолютно не в виде нестандартного, более мощного, интерфейса, а в виде... Удачное высказывание - грех не процитировать:

dottedmag: UI неконсистентен совсем

Абсолютно неконсистентен. Можно плюнуть на 146 (!) файлов в /usr/bin (из которых больше ста - компилированные бинарники): они, типа, соответствуют никсовой философии "одна утилита для одной задачи" (на мой взгляд, git в общем выполняет очень даже одну задачу - хранение версий моих данных) - это, кстати, собираются вроде в скором будущем поправить. Но самый простой пример - выбивает из колеи. Для меня являлось нормальным создавать клон репозитория удалённо простой командой:

hg clone byteflow ssh://piranha@piranha.org.ua/dev/byteflow

Репозиторий клонирован. Я могу, опять же по ssh, забрать его. Могу настроить web-доступ для него (опять же, если я настроил весь ~/dev/ показывать в веб-морде, и без этого можно обойтись). В git'e... читаем хелп:

<repository>
The (possibly remote) repository to clone from. See the URLS section below for more information on specifying repositories.
<directory>
The name of a new directory to clone into.

Это мелочь. Я могу поставить sshfs (ха, если я не в винде сижу!), и склонировать как будто бы в локальную директорию. Но эти мелочи идут сквозняком через весь интерфейс git'а, что приводит к значительно более раздражающей меня проблеме - адресам у веб-интерфейса. Достаточно сравнить:

• http://git.catap.ru/?p=emacs-jabber.git;a=blob;f=jabber-chatbuffer.el;hb=HEAD
• http://hg.piranha.org.ua/byteflow/file/tip/urls.py

Из обоих убраны идентификаторы ревизии (заменены на символические аналоги последней ревизии - HEAD и tip). Что легче прочитать? Запомнить? Я очень часто набираю ссылки по памяти, но с git'ом этот фокус провернуть на порядки сложнее.

Ещё одна проблема с адресами - у меркуриала один и тот же адрес является адресом веб-интерфейса и адресом для самого клиента меркуриала: надо помнить лишь один адрес. С гитом этот номер не прокатит - попробуй догадайся про адрес у первого репозитория без подсказки? Тут повезло, всего лишь git://git.catap.ru/emacs-jabber. Но... интерфейс, это интерфейс...

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

Продвигаемся вперёд по плану гнобления¹: набор команд. Не видел ни разу человека, набиравшего команду status полностью - все пишут st. Обломитесь - в гите нельзя сокращать команды. Нету автоматических (ну конечно, всегда можно сделать алиасы) st, ci, и вообще никаких сокращений команд - при этом в меркуриале кроме предустановленных сокращений хватает любого набора букв, достаточного для несомненного определения команды.

А что мы можем сказать о помощи? У систем огромное количество команд и возможностей. Помощь в меркуриале - это информация по сути дела. hg help clone - одна страница с описанием поведения при разных условиях и списком специфических опций. git help clone - 4 страницы текста. Зачем мне столько? Я хочу краткий хелп, а не руководство. Руководство должно быть в man-pages или в виде книжки. Когда у меня есть только медленная консоль, это не может не раздражать.

На этом претензии, накопленные не к фичам гита, у меня пока исчёрпываются - можно лишь благодарить богов, что мне не приходится это чудо использовать так же много, как и меркуриал. К фичам придраться тоже можно было бы, но этого и так хватает в интернетах - к примеру, отсутствие удобного аналога mq.

К завершению подойду полупинком (почему "полу" - об этом позже) в сторону меркуриала. В гите есть довольно удобная штука в виде бранчей. Это что-то типа внутрирепозиторийных клонов (можно провести прямую аналогию с директориями trunk и branch, являющихся обычным приёмом при работе с svn). Самый большой прикол заключается в том, что бранчи в полный рост реализованы в меркуриале - но никаким образом не реализована удобная работа с ними:

• hg fetch (который является склеенным скачиванием обновлений и автоматическим их мержем) может поломаться, когда изменения для мержа есть в нескольких ветках.
• tip стоит не на основной ветке, а на последнем коммите.
• hg backout не проверяет, из текущей ли ветки запрашиваемый чейнджсет, или нет.
• hg push определяет создание нескольких "голов²" только для текущей ветки.

Почему это полупинок? По двум причинам:

1. На большинство проблем уже заведены баги, и работа над ними ведётся, хотя это и слабая отмазка. :-)
2. В большинстве случаев использование бранчей неоправданно и их замена обычными клонами (отдельными репозиториями) создаёт куда более прозрачный цикл работы.

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

В принципе, замечания по поводу "это лучше, а это хуже" - приветствуются, особенно личные и субьективные (субьективные не в плане "я щетаю шо субверсион рулед и капец!" ;). Ссылки на статьи... я бы предпочёл пережёванные мысли комментирующих, потому что статей уже сам почитал - пока ни одной вменяемой git vs hg, где гит был лучше, не видел. В основном фанаты какие-то.

P.S. Тут в статье случайно мелькнуло слово svn. Чтоб развеять сомнения в моей ориентации, спешу сообщить - я натурал, svn ненавижу за крайнюю угрёбищность и перманентную порчу последнего года жизни. :-)