А у него как минимум один форк: url=https://bitbucket.org/mponomarenko/hg-fixutf8

До 2011-го в консоли^Wcmd.exe ни одно нормально не заработало, пришлось допиливать своё https://bitbucket.org/mecareful/hg-fixutf8-backbone.

Но, имхо, как в Gitorious private-repos домержат, свалю на Git. Скорость и сжатие лучше, возможность безболезненного удаления веток без необходимости делать клоны или ставить расширения.
Что касается преобразования кодировок, то костыли это, имхо, и не нужно кроме UTF-8. Либо уж имена в латинице.
Что, если Вы создали репозиторий, в именах файлов которого >256 символов. Назад их преобразовать уже не получится даже в теории.

Скорость и сжатие лучше

возможность безболезненного удаления веток без необходимости делать клоны или ставить расширения.

/me пожимает плечами в полном недоумении. Скорость чего, какие объемы тебе сохраняет разница в степени сжатия, с каких пор «безболезненное удаление веток без SMS^Wрасширений» стало важным юзкейсом?

hg-git отлично работает (правда, медленно).

hg clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

Скорость клонирования репов. Волей судьбы приходится прыгать между компами.
Сжатие у Git выше раза в 3 в среднем, чем у Mercurial, мне это важно.
Удаление ненужных веток тоже важно. Конфиги храню в Mercurial, репозиторий быстро растёт.

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

Скорость клонирования репов.

Неужели? Вообще-то и в Git, и в Mercurial клонирование в пределах локальной ФС производится хардлинками. Что, для Git вызов link(2) работаепт быстрее?

Волей судьбы приходится прыгать между компами.

Мде. А судя по «свалю на Git» («свалю» - единственное число) ты используешь Git в чисто персональных целях и/или на короткоживущих проектах?

Сжатие у Git выше раза в 3 в среднем, чем у Mercurial

4.2

Удаление ненужных веток тоже важно. Конфиги храню в Mercurial, репозиторий быстро растёт.

А для программироваания ты Mercurial вообще используешь или нет? Потому что я не представляю себе, как можно программировать, но не включить при этом mq (одна строчка в конфиге).

P.S. насчет «расширений»...

$ file /usr/bin/git-merge
/usr/bin/git-merge: POSIX shell script text executable
$

в этом вашем Git без расширений и шагу не ступишь.

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

а я пытался ту же репу из линукса слить - угадайте результат...

нет ли какого-нибудь hard fix? костыля какого-то, чтоб всё нормально было?

да... и раз уж тебя про bazaar - в нём таких проблем нет?

Неужели? Вообще-то и в Git, и в Mercurial клонирование в пределах локальной ФС производится хардлинками. Что, для Git вызов link(2) работаепт быстрее?

Я не спорю на счёт теории, простые тесты показывают, что git clone быстрее отрабатывает.

Мде. А судя по «свалю на Git» («свалю» - единственное число) ты используешь Git в чисто персональных целях и/или на короткоживущих проектах?

Свалю на личных проектах (если dcvs пользуется один человек в команде, то это проблема, я в курсе).

4.2

Ну сами потестируйте, зачем спорить? git gc разве что на бинарных файлах не даст выигрыша.

А для программироваания ты Mercurial вообще используешь или нет? Потому что я не представляю себе, как можно программировать, но не включить при этом mq (одна строчка в конфиге).

┌─[kolan@corka (13:26)]──(~)
└─[% > grep mq .hgrc                                                                                                                                                                (hg)-[/desktop/gentoo/kolan/corka] 
mq =

обхожусь пока что.

нет ли какого-нибудь hard fix? костыля какого-то, чтоб всё нормально было?

Этот костыль придётся устанавливать пользователю Windows, может это http://code.google.com/p/utf8-git-on-windows/downloads/list.

Я не спорю на счёт теории, простые тесты показывают, что git clone быстрее отрабатывает.

На каких репозиториях проверено?

Ну сами потестируйте, зачем спорить?

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

git gc разве что на бинарных файлах не даст выигрыша.

Мде. Причем git gc к бинарным файлам? Это костыль для чистки базы объектов от мусора.

обхожусь пока что.

Я ничего не понял из твоего ASCII-арта, но, если ты обходишься без mq, то учи матчасть, окупится.

Да что вы спорите, самая лучшая VCS это Team Foundation Server, я гарантирую!

На каких репозиториях проверено?

Я тестировал на личных репозиториях, но вот, к примеру, ссылка на тесты с OpenSource проектами http://vcscompare.blogspot.com/2008/06/git-mercurial-bazaar-repository-size.html

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

Может быть, я не знаю, меня тогда не было.

Мде. Причем git gc к бинарным файлам? Это костыль для чистки базы объектов от мусора.

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

Я ничего не понял из твоего ASCII-арта, но, если ты обходишься без mq, то учи матчасть, окупится.

ок.

вот, к примеру, ссылка на тесты с OpenSource проектами http://vcscompare.blogspot.com/2008/06/git-mercurial-bazaar-repository-size.html

Тесту скоро 4 года, и там опять же нет 3-кратного превосходства git над hg.

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

Да и не должно (особенно если настроен автозапуск gc).

да... и раз уж тебя про bazaar - в нём таких проблем нет?

У базара с юникодом полный порядок.

Кстати, у «отсталого» SVN тоже, как выяснилось.

автозапуск gc

Спасибо, посмотрю.

Сегодня вышла система контроля версий от Canonical.

Для соблюдения точности формулировок поправлю, что Canonical лишь только спонсирует разработку (не знаю, как выглядит это спонсорство), но Bazaar - это часть проекта GNU.

http://bazaar.canonical.com/en/

What is Bazaar?

Bazaar is a version control system that helps you track project history over time and to collaborate easily with others. Whether you're a single developer, a co-located team or a community of developers scattered across the world, Bazaar scales and adapts to meet your needs. Part of the GNU Project, Bazaar is free software sponsored by Canonical.

Скажу по секрету: оно кроме самой Canonical никому не нужно. Все нормальные люди пользуются либо Git, либо Hg.

GNU использует Bazaar. Например, для разработки Emacs и др.

Заходишь в тему - и правда, базар.

И модераторам жаловаться бессмысленно.

У меня в Far стоит Consolas, Lucida еще обычно идет в комплекте.

Убейся об стену.

Вообще-то mq с его разными «фронтэндами» уже давно в основном пакете. Ветки удаляются совершенно без проблем.

Вообще-то mq с его разными «фронтэндами» уже давно в основном пакете. Ветки удаляются совершенно без проблем.

Работает, спасибо!

нет. это потому, что человек чувствует себя комфортно только с теми инструментами, к которым привык (то есть с «любимыми»), а на переучивание требуется время ;)

Оно сжимать научилось (а-ля git) или все так же, можно посадить дерево/построить дом/etc пока качаются сорцы grub?

зачем оно? есть же svn и git.

Дааа. Живут же люди!
Мне-то до сих пор на работе приходится Visual SourceSafe использовать. Убийственная вещь - например, недавно втихую и по непонятным причинам сделала Undo check-out у коллеги, и двухдневный труд пошел коту под хвост.
Ладно хоть бэкапы были.

Мне-то до сих пор на работе приходится Visual SourceSafe использовать. Убийственная вещь - например, недавно втихую и по непонятным причинам сделала Undo check-out у коллеги, и двухдневный труд пошел коту под хвост.

ухаха, отмучался я на нем в свое время, как щас помню:

«Эй, друг, собери проект, плиз! А то у меня измененения, которые пока засылать нельзя!»

Мне-то до сих пор на работе приходится Visual SourceSafe использовать.

Нафиг такую работу, нервы дороже.

потому что git grep сделан для тех, кому лень написать “grep pattern $(hg locate)”.

Спасибо, было смешно.

> потому что git grep сделан для тех, кому лень написать “grep pattern $(hg locate)”.

Спасибо, было смешно.

А что не так? «hg grep» ищет в diff’ах и показывает, когда была добавлена определённая строка. «git grep» без указания ревизии работает именно как «grep pattern $(hg locate)» («grep pattern $(git ls-files)»). Если надо искать именно в другой ревизии, то придётся использовать «hg update» и, опять же, обычный grep.

в этом вашем Git без расширений и шагу не ступишь.

А при чем тут git-merge?

При том, что куча функциональности в git реализуется внешними скриптами. В Mercurial в таких случаях используются расширения.

Во-первых, git-merge уже нет:

$ which git-merge
which: no git-merge

Во-вторых, чем плохи скрипты?

Я не говорил, что они плохи.

Они делают из «the stupid content tracker» DVCS.

Это всё еще plumbing вместо DVCS.

Во-вторых, чем плохи скрипты?

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

Только git grep делает это со скоростью, в разы, если не на порядки, превышающей grep -R *. Я понимаю, на хелловорлдах это, может, и не заметно, а когда в проекте закоммитано 56K файлов - разница, знаете ли, на лице.

Лично я для себя отметил что vasilenko скромно умолчал о CVS что выдаёт махровый коллаборационизм и комплексы. Далее, у того кто использует bzr одновременно с живым git явно не пионерский ум, а старческий маразм.

По теме можно добавить что по-умолчанию надо использовать не сраный utf-*, а сраную локаль, и делать как там написано.

i18n.comitenconding=koi8-r или cp1251

можно попровать дальше по man-у что-то и про файлы было.

Bazaar не нужен. Развели, понимаешь, целый зоопарк dvcs...

Bazaar не плох.. и Git тоже..

удачи обоим проектам! :-)

Багрепорт ты отправил, надеюсь?

Нет, конечно.

1. как оказалось, баз уже был давно известен но никто его не фиксил. Что удивительно. Как-никак один из любимых продуктов Canonical.

2. на моей памяти, баги, что я репортил, как правило либо вообще никто не смотрел, либо закрывали с пометкой «так и задумано». Свежий пример - падучий weather applet. Никто и не собирается фиксить.

И год назад и сейчас работает идеально с дефолтными настройками. Ставил как бинарники MsysGIT, так и самособирающуюся версию.
Но я жосский виндузятник и в консоль редко лезу окромя как написать git init, git clone. В основном пользуюсь GitExtensions.

А я пускал в Ubuntu стандартный GUI этого Bazaar. В теории, это должно быть самым стабильным подходом: дистр поддерживается теми же товарищами, что занимаются Bazaar. И в GUI чисто физически нельзя сделать слишком извращенные вещи. Да я и не собирался делать ничего особенного. Но зараза не работала. Пять минут траха, три минуты гугления, найденная не закрытая проблема -> ф топку.

i18n.comitenconding=koi8-r или cp1251

Да ну нафиг. Не для того мы utf-8 внедряли, чтобы в репе эти кодировк были.

А я пускал в Ubuntu стандартный GUI этого Bazaar.

У Bazaar появился стандартный GUI?! Это bzr-gtk или qbzr так обозвали?

Re

вобщем плюсы:

1) нормальная поддержка винды, 2) местами более прямой чем git особенно в плане переименования файлов и каталогов

недостатки:

1) тормоз ибо пайтон 2) нерассчитан на работу с бинарными файлами

Во-вторых, чем плохи скрипты?

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

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

А я пускал в Ubuntu стандартный GUI этого Bazaar.

У Bazaar появился стандартный GUI?! Это bzr-gtk или qbzr так обозвали?

Тот, что Bazaar Explorer. Думаю он сделан на базе qbzr.

А стандартный он в том смысле, что его первым предлагают.

1. Идешь на http://bazaar.canonical.com/en/

2. Тыкаешь на «extras» и видишь что в категории «GUI Clients» есть только Bazaar Explorer и ссылка на «3rd party tools».

Так что Bazaar Explorer явно представлен людьми, отвечающими за bazaar как основной GUI. :-) Ты им не веришь?

Не верю. Тем более explorer долго в полузамороженном состоянии был.

Вот qbzr активно разрабатывается.

Оно тоже не умеет докачку?

Я где‐то написал “grep -R *”? Не надо заставлять grep дёргать каталоги, на больших репозиториях используйте xargs:

(zyx:tmp/image/linux) % time git grep abc &>/dev/null
git grep abc &> /dev/null  8,92s user 0,54s system 6% cpu 2:16,09 total
(zyx:tmp/image/linux) % time grep abc -R * &>/dev/null
grep --color=auto abc -R * &> /dev/null  3,45s user 0,47s system 9% cpu 42,277 total
(zyx:tmp/image/linux) % time git grep abc &>/dev/null 
git grep abc &> /dev/null  3,78s user 0,46s system 40% cpu 10,553 total
(zyx:tmp/image/linux) % time grep -P abc -R * &>/dev/null
grep --color=auto -P abc -R * &> /dev/null  3,15s user 0,32s system 87% cpu 3,969 total
(zyx:tmp/image/linux) % time grep -F abc -R * &>/dev/null
grep --color=auto -F abc -R * &> /dev/null  0,72s user 0,31s system 95% cpu 1,086 total
(zyx:tmp/image/linux) % time grep -P abc -R * &>/dev/null
grep --color=auto -P abc -R * &> /dev/null  3,01s user 0,28s system 98% cpu 3,337 total
(zyx:tmp/image/linux) % time git grep abc &>/dev/null    
git grep abc &> /dev/null  1,90s user 0,19s system 322% cpu 0,649 total
(zyx:tmp/image/linux) % time ( git ls-files -z | xargs -0 grep abc ) &>/dev/null
( git ls-files -z | xargs -0 grep abc; ) &> /dev/null  0,72s user 0,34s system 90% cpu 1,174 total
(zyx:tmp/image/linux) % time ( git ls-files -z | xargs -0 grep -F abc ) &>/dev/null
( git ls-files -z | xargs -0 grep -F abc; ) &> /dev/null  0,79s user 0,30s system 101% cpu 1,072 total

На первый результат смотреть не надо — это ещё кэши не заполнились.

В любом случае, что для “git grep”, что для “git ls-files | xargs grep” узким местом является файловая система и нет ровно никакой разницы, что именно использовать.

Проверялось на исходном коде ядра.

Так что покажите репозиторий, где разница будет.