Доступны результаты (http://laserjock.wordpress.com/2008/05/09/bzr-git-and-hg-per.../) сравнения производительности систем управления исходными текстами bzr (Ubuntu Bazaar), git и hg (Mercurial).
Наилучшую производительность продемонстрировал Git. Mercurial оказался в среднем в 2.75 раза медленнее Git, Bazaar при этом отстал от Git в 5 раз.
Подробнее:- Инициализация репозитория: git (0.086s), bzr (0.334s), hg (0.137s);
- Добавления в репозиторий исходных текстов Linux ядра 2.6.0: git (14.269s), bzr (4.852s), hg (2.526s);
- Коммит дерева исходных текстов Linux ядра 2.6.0: git (10.263s), bzr (43.968s), hg (30.890s);
- Формирование diff для ядра 2.6.25.2: git (24.425s), bzr (51.158s), hg (37.846s);
- Коммит большого блока изменений: git (28.468s), bzr (1m8.627s), hg (47.948s);
- Формирование diff, без предшествующих изменений: git (0.343s), bzr (47.448s), hg (1.340s);
- Получение ст...URL: http://laserjock.wordpress.com/2008/05/09/bzr-git-and-hg-per.../
Новость: http://www.opennet.ru/opennews/art.shtml?num=15803
Да...
Торвальдс реально силен :)Такую вещь написал!
Несложно победить унылое говно на питоне. Надо было сравнивать с SVN
>Несложно победить унылое говно на питоне. Надо было сравнивать с SVNой, лучше не надо... Ато после такого сравнения еще больше проектов перейдут с SVN'а на Git.
Сам около года пользовал SVN для всего и вся. Как асилил Git - прозрение было неслабым.
Времени на SVN было убито немало.... он тормоз :)Git - реально сильная вещь.
>Несложно победить унылое говно на питоне. Надо было сравнивать с SVNа этим еще кто-то пользуется?
>>Несложно победить унылое говно на питоне. Надо было сравнивать с SVN
>
>а этим еще кто-то пользуется?5 %)
>Несложно победить унылое говно на питоне. Надо было сравнивать с SVNпростите.. где вы увидели питон? подавляющая часть GIT написана на C.
он имел в виду mercurial, а не git
имел ввиду он bzr, а не mercurial, и не git.
В Bzr, в общем-то, скорость - не основное направление.
а чего git Линус написал? хм я думал он тока ядро ковыряет :)
>а чего git Линус написал? хм я думал он тока ядро ковыряет
>:)По крайней мере начал, а там уже и другие разработчики допиливали.
>а чего git Линус написал? хм я думал он тока ядро ковыряет
>:)чтоб эффективно его и продолжать писать - он себе сделал инструмент.
>а чего git Линус написал? хм я думал он тока ядро ковыряет
>:)Линус очень долго пользовался закрытой программой для тех же целей BitKeeper. Получалось что вроде бы linux - флагман свободных программ, а самый главный инструмент - закрыт. Очень долго Линуса пинали за это, но он отшучивался и отмахивался. Главная отмазка была - нет подобных средств, и точка. Насколько я понимаю, ему очень нужна была фича BitKeeper и git по rebase и нормальное merge с учетом всей предыстории.
Время шло, нападки на Линуса были чаще и сильнее, и тут подвернулся повод - разработчик BitKeeper'a что то там снова решил поменять в лицензии. В итоге Линус не выдержал, и написал GIT.
Практически не соврал :)Не, все на месте вроде бы.
>Время шло, нападки на Линуса были чаще и сильнее, и тут подвернулся
>повод - разработчик BitKeeper'a что то там снова решил поменять в
>лицензии.Не совсем так. Larry McVoy (владелец? BitKeeper) был спровоцирован Andrew Tridgell (автор Samba), который помалу начал реверсить протокол (что запрещено лицензией bk -- уж не знаю, насколько на это пофиг в Австралии). Туда-сюда, в итоге Тридж не обращал внимания на иные взывания "да прекрати уж", Ларри в какой-то момент психанул и сказал, что bk free заканчивается, дав три месяца на всем свалить куда-нибудь, cvs-ный экспорт (подробностей не помню, но сделан он был задолго до того) и после этого подняв версию протокола.
>В итоге Линус не выдержал, и написал GIT.
Примерно.
Скажем так -- идеи туда пошли из лучшего, что было разработано на то время, насколько могу судить. Бишь никакое SVN рядом не валялось принципиально. А bzr на удивление неплохо охарактеризовал аноним выше -- искренне непонятна явно политическая позиция Шаттлворта, который это непотребство финансирует и пропихивает (впрочем, дальше launchpad никуда оно особенно не пропихнулось), и Столмана, который это непотребство взялся рекомендовать.
Оно ж действительно технически несостоятельно.
Если кому интересно получить своих ощущений -- поработайте, желательно с прыжками через версии репо и питона, ну или почитайте man bzr в районе описания "bzr init" (зачем было рожать формат, где отдельному бранчу нужен отдельный каталог со всеми вытекающими -- моя опять искренне не понимать).
Ссылки по теме:
http://www.infoq.com/articles/dvcs-guide
http://betterexplained.com/articles/intro-to-distributed-ver.../
2.6.25.3 10 May 2008 311M
Упс, строки забыл...Лень проверять, но помоему вот так должно заработать:
# cd /usr/src/linux-2.6.25.3# count=0; for i in `find ./ -depth -name \*.[Sch] -exec wc -l '{}' \; | awk '{print $1}'`; do count=$(( $count + $i )); echo $count; done;
Вот что вышло - 8396615 строк
Любишь сложности :)Почему не find ... | xargs cat | wc ?
>Любишь сложности :)
>
>Почему не find ... | xargs cat | wc ?САТу может и бинарник попасться, тогда уж через strings. (а если честно, не думал, последующий конвейер сам, походу, придумывается) :)
>Упс, строки забыл...Лучше sloccount, imho.
Сразу и не фтыкнул - оригинал называет "Linux Kernel Growth: 0.01-to-2.6.18 (1991-2006)"А чё они до 05.2008 НИАСИЛИЛИ....
обьясняется почему SVN и GIT в разных весовых категориях.Linus Torvalds on git:
http://www.youtube.com/watch?v=4XpnKHJAok8
>обьясняется почему SVN и GIT в разных весовых категориях.
>Linus Torvalds on git:
>http://www.youtube.com/watch?v=4XpnKHJAok8угу, смотрели.
Но сути не меняет. Git полностью покрывает функционал SVN'а (в том числе и серверная эмуляция оного), а еще Git и более производителен.
Выбор очевиден.
>Но сути не меняет. Git полностью покрывает функционал SVN'а (в том числе
>и серверная эмуляция оного), а еще Git и более производителен.
>Выбор очевиден.Для нас с Вами -- угу, а вот для виндузятников и ынтерпрайза не совсем так: первым важна доступность инструмента и интеграции с IDE на виндах, вторым -- дубовость SVN (в том же плане, что и жабы -- чтоб кодеры ходили предсказуемым строем) и killer app по имени trac ;-)
Детишки это вы. А Линусу было на чем потренироватся и обдумать как все должно работать, перед началом разработки git.> а потом плакались что народ пишет её опенсорс аналог
> (по-моему последнее - это как раз git).Нет не git
> Собственно, вопрос - где эти недоучки сейчас?
Полагаю там же где и были и занимаются тем же.
ИМХО: если такая штука как линукс кернель засовывается за считанные секунды, то разница в 5 раз погоды не делает.То есть оно круто но если оно на практике столь большой проект за максимум десятки секунд разруливает - можно выбирать любой манагер версий и не греть мозг этим вопросом, взяв за критерии что-то более важное чем считанные секунды задержек на проекте уровня линуксного кернеля :)
>ИМХО: если такая штука как линукс кернель засовывается за считанные секунды, то
>разница в 5 раз погоды не делает.То есть оно круто но
>если оно на практике столь большой проект за максимум десятки секунд
>разруливает - можно выбирать любой манагер версий и не греть мозг
>этим вопросом, взяв за критерии что-то более важное чем считанные секунды
>задержек на проекте уровня линуксного кернеля :)если.
Я юзал SVN для управления сырцами ядра с год. Мажорный патч с версии на версию (например 2.6.20 -> 2.6.21) занимало закоммиттить 20 минут...
Git же за пару десятков секунд сделает это, да еще и без необходимости руками качать дифф, распаковывать и патчить проект. "git pull" + ~20-30 секунд = новая версия.
Это не идет ни в какое сравнение с геммором SVN, хоть и немалую (но не главную) роль тут играл сам факт хранения ядра в Git'е.
>>Это не идет ни в какое сравнение с геммором SVN, хоть и немалую (но не главную) роль тут играл сам факт хранения ядра в Git'е.По моему, как раз главную. Тормоза связаны именно с тем, что при парсинге diff-а нужно протоколировать это в истории локальных изменений. Понятно, что для Git-а это не требуется (поскольку рабочая версия просто up-to-date).
Ну, и правило буравчика таково - какой CVS использует проект, над которыми работаете, то ту же VСS используете и вы. Чтоб потом не появлялись рассказы о страшных тормозах той или иной VСS...
>Ну, и правило буравчика таково - какой CVS использует проект, над которыми
>работаете, то ту же VСS используете и вы. Чтоб потом не
>появлялись рассказы о страшных тормозах той или иной VСS...Следуя этой рекомендации, можно появить ещё не один рассказ про тормоза Bazaar или SVN :)
>Я юзал SVN для управления сырцами ядра с год. Мажорный патч с версии на версию (например 2.6.20 -> 2.6.21) занимало закоммиттить 20 минут...А что было сервером - httpd или svnserve ???
Если через httpd - то чему удивляться ? он сам тормоз.
>>Я юзал SVN для управления сырцами ядра с год. Мажорный патч с версии на версию (например 2.6.20 -> 2.6.21) занимало закоммиттить 20 минут...
>
>А что было сервером httpd или svnserve ???
>Если через httpd - то чему удивляться ? он сам тормоз.сервером была ФС (ext3, Dual Opteron 246 2GHz, 3ware 9550SX raid5).
Но столько времени занимал коммит всего ядра, а не мажорного патча (подзабыл, давно дело было ;)
вот берем тарбол, растариваем "... add" и "... ci" и на наццать минут идем гулять.
Это НЕ работа с исходниками масштабов ядра. И Торвальдс это четко по-русски :) в
своем выступлении сказал.
щас попробовал Git'ом это же сделать.# wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.25.3.t...
# tar xjf linux-2.6.25.3.tar.bz2
# cd linux-2.6.25.3
# git init
# git add *
# time git commit -a -m 'init'real 0m15.077s
user 0m6.814s
sys 0m0.877sСогласитесь, достаточно быстро.
собираю svn. как тока так и запосчу результаты.
все же лучше перепроверить ;)
ибо мнооого воды утекло :)
не хотелось бы отстаивать ошибочную точку зрения :)
Собсно:tar xjf linux-2.6.25.3.tar.bz2
cd linux-2.6.25.3/
mkdir -p ~/.r/l-25.3
svnadmin create ~/.r/l-25.3
svn co file:///root/.r/l-25.3 .
svn add *
time svn ci -m "Commit message"
..........................................
.....
...................................................
Committed revision 1.real 16m23.962s
user 2m24.640s
sys 0m29.383sэто даже не избитие младенца... это ужасно...
Может я конечно "не так" его пользовал. Ну по манам так вещают.
Кроме того, СИЛЬНО расстраивали диры ".svn" на всех уровнях
структуры дерева исходников. Приходилось делать обертку для грепа...
ибо такое находилось OMG... . В гите - репозиторий это всего лишь одна дира ".git" в корне проекта. grep-friendly :)
Также весьма за...^w малоприятно в SVN'е категорическое невосприятие относительных путей к дире с репозиторием (уж молчу о том, что его нужно обязательно хранить вне проекта).Я тогда любил SVN и серьезно полагал, что сие есть праведные страдания
за правое дело и ничего лучше быть не может. ...пока не решился
асилить Git :)Ничего не имею против SVN'а. Для своего времени (лет 5 назад)
это была МОЩЬ. Это был прорыв по отношению к CVS!
Но ведь нет ничего страшного, что за это время появились
другие инструменты, учитывающие недостатки существующих.
Это естественный процесс. И на Git когда-нибудь найдется управа.
И вся наша задача состоит лишь в том, чтобы своевременно обновлять свои инструменты и не терять драгоценное время [лицезрея горы бегущих точечек SVN'а %))].
>[оверквотинг удален]
>асилить Git :)
>
>Ничего не имею против SVN'а. Для своего времени (лет 5 назад)
>это была МОЩЬ. Это был прорыв по отношению к CVS!
>Но ведь нет ничего страшного, что за это время появились
>другие инструменты, учитывающие недостатки существующих.
>Это естественный процесс. И на Git когда-нибудь найдется управа.
>И вся наша задача состоит лишь в том, чтобы своевременно обновлять свои
>инструменты и не терять драгоценное время [лицезрея горы бегущих точечек SVN'а
>%))].Есть специальная команда svn import
$tar xjvf linux-2.4.31.tar.bz2
$mkdir -p ~/.r/l-2431
$svnadmin create ~/.r/l-2431/
$cd linux-2.4.31
$svn import ./ file:///home/mike/.r/l-2431 -m '...'
....
$time svn co --non-interactive file:///home/mike/.r/l-2431 ./
....
Checked out revision 1.real 1m22.761s
user 0m40.970s
sys 0m17.850sНе надо выступать, что 1 минута затормозит вам всю работу над проектом.
>Есть специальная команда svn import
>real 1m22.761s
>user 0m40.970s
>sys 0m17.850sхм....
неплохо.Ессьно, чувствуется, что при том долгом коммите svn занимается переливанием из пустого в порожнее. Много раз.
Ну и отлично что есть команда порасторопнее :)
>Не надо выступать, что 1 минута затормозит вам всю работу над проектом.замедлит невозможность легкого портирования из одной ветки разработки в другую.
Греп по этим .svn дирам замедлит, тормоза с просмотром лога, который только на серваке
может (пока что) лежать.
Во имя чего терпеть такие лишения? Я не вижу смысла.
>[оверквотинг удален]
>Ну и отлично что есть команда порасторопнее :)
>
>
>>Не надо выступать, что 1 минута затормозит вам всю работу над проектом.
>
>замедлит невозможность легкого портирования из одной ветки разработки в другую.
>Греп по этим .svn дирам замедлит, тормоза с просмотром лога, который только
>на серваке
>может (пока что) лежать.
>Во имя чего терпеть такие лишения? Я не вижу смысла.Держать единый репозиторий, и прочие плюшки связанные с администрированием этого репозитория. Хотя, чувствуется. что квалификация команды Субвершен оставляет желать лучшего (не Линусы Торвальдсы они, да), но это лучшее в этом смысле, что есть на сегодняшний день. На самом деле они первые, кто реализовал спеки WedDAV (которая как раз и включала систему контроля версий, но сейчас это существует только в виде субвершеновского модуля для апача).
GIT всё же остается несколько в виде PtP (как и его аналоги). Может это и ничо, но как-то более привычно ощущать себя в клиент-серверной архитектуре.
>Держать единый репозиторий, и прочие плюшки связанные с администрированием этого репозитория.Ну, вот посмотрите http://git.kernel.org
новые репозитории заводятся крайне просто (как раз сседня сетапил).
Правда, не скажу насколько просто подобное можно сделать для svn.
Но, оприори, разницы здесь нет. И то и то может быть "все в одном месте".
А кроме того, git сервак может эмулировать svn сервер... ;)>Хотя,
>чувствуется. что квалификация команды Субвершен оставляет желать лучшего (не Линусы Торвальдсы
>они, да), но это лучшее в этом смысле, что есть на
>сегодняшний день.из централизованных средств - возможно.
>На самом деле они первые, кто реализовал спеки WedDAV
>(которая как раз и включала систему контроля версий, но сейчас это
>существует только в виде субвершеновского модуля для апача).Да, первые... но за первыми всегда идут вторые, которые при правильном подходе
обгоняют первых.
Ну вот что толку в этих их достижениях сейчас. Мне будет надо - я сделаю себе WebDAV
в апаче. И для этого мне не понадобится даже знать кто его первым пользостью реализовал...
Это борьба... Первый не всегда лучший. Более того. Держать первенство несколько сложнее,
чем добиться его. Что мы и видем. SVN размышляет над тем, чтобы реализовать некотороую функциональность децентрализованных систем.
>GIT всё же остается несколько в виде PtP (как и его аналоги).угу. А современность четко показывает, что разница между сервером и клиентом
все больше размывается. Клиентские тачки уже давно с 2мя процами и вагонами памяти.
Еще большой вопрос кто мощьнее: такой десктоп или 2 летней давности сервак...Так что PtP подход вполне естественен.
>Может это и ничо, но как-то более привычно ощущать себя в
>клиент-серверной архитектуре.Ну, привычно - это дело далеко не технического плана ;)
Это привычка... лень учить новое... Это естественно для человека :)
Нафига шо-то делать, если и так работает. И это нормально :)
Но технически это пустой звук :)
>[оверквотинг удален]
>$time svn co --non-interactive file:///home/mike/.r/l-2431 ./
>....
>Checked out revision 1.
>
>real 1m22.761s
>user 0m40.970s
>sys 0m17.850s
>
>Не надо выступать, что 1 минута затормозит вам всю работу над проектом.
>tar xjvf linux-2.6.25.3.tar.bz2
mkdir -p ~/.r/l-2431
svnadmin create ~/.r/l-2431/
cd linux-2.6.25.3
svn import ./ file:///alick/.r/l-2431 -m '...'
....
Committed revision 1.time svn co --non-interactive file:///alick/.r/l-2431 ./
....
Checked out revision 1.real 0m2.083s
user 0m0.005s
sys 0m0.003s
>[оверквотинг удален]
>асилить Git :)
>
>Ничего не имею против SVN'а. Для своего времени (лет 5 назад)
>это была МОЩЬ. Это был прорыв по отношению к CVS!
>Но ведь нет ничего страшного, что за это время появились
>другие инструменты, учитывающие недостатки существующих.
>Это естественный процесс. И на Git когда-нибудь найдется управа.
>И вся наша задача состоит лишь в том, чтобы своевременно обновлять свои
>инструменты и не терять драгоценное время [лицезрея горы бегущих точечек SVN'а
>%))].tar xjf linux-2.6.25.3.tar.bz2
cd linux-2.6.25.3/
mkdir -p ~/.r/l-25.3
svnadmin create ~/.r/l-25.3
svn co file:///root/.r/l-25.3 .
svn add *
time svn ci -m "Commit message"Committed revision 1.
real 2m9.366s
user 1m13.496s
sys 0m40.178s
А теперь с гитом сравни у себя ;)
>>А что было сервером httpd или svnserve ???
>>Если через httpd - то чему удивляться ? он сам тормоз.
>
>сервером была ФС (ext3, Dual Opteron 246 2GHz, 3ware 9550SX raid5).А это тут при чем?????
Речь идет о том, какой сервер (прога!!!) был использован в качестве репозитария -свой (svnserve) или httpd с mod_dav_svn? В случаи httpd ни о какой скорости речь не может идти, но зато очень удобно ходить через всякие блокирующие прокси.
какие прокси, мил человек?...Речь о производительности даже на локальной ФС. Нейтрализуя влияние сети и другой системы.
Просто с винта тут же на него коммитить. Лично мне так было нужно, потому как я ни с кем не разделял эту работу. Мне нужен был всего-лишь контроль версий.
>какие прокси, мил человек?...Например squid :))))) но в вашем случаи он ни причем.
>Речь о производительности даже на локальной ФС. Нейтрализуя влияние сети и другой
>системы.Ну и как удалось нейтрализовать "влияние сети и другой системы" ???? Или все же через httpd долбились - на каждый файл по десяток запросов????
вот попробуйте разные транспорты, тогда и можете сказать о скорости.
Или вы не в курсе что svn может работать по разному??? И с разной скоростью??
>>Или все же через httpd долбились - на каждый файл по десяток запросов????Не тупи. Когда репозиторий находится на file:///, то svn работает без сервера. Нужен только клиент.
>>>Или все же через httpd долбились - на каждый файл по десяток запросов????
>
>Не тупи. Когда репозиторий находится на file:///, то svn работает без сервера.
>Нужен только клиент.Не тупи!!! С чего ты взял что был file:///???? У меня с ним летает!!!
Я думаю там у Nick был классический https
>>>>Или все же через httpd долбились - на каждый файл по десяток запросов????
>>
>>Не тупи. Когда репозиторий находится на file:///, то svn работает без сервера.
>>Нужен только клиент.
>
>Не тупи!!! С чего ты взял что был file:///???? У меня с
>ним летает!!!
>Я думаю там у Nick был классический httpsне надо думать
надо у Ника спросить.А было все просто: я брал тарболы на кернельорге и мне просто нужно было с ними как-нить "бороццо". Я просто на _одной_ тачке пользовал SVN. Ессьно ниче кроме file:/// не было нужно. Тормоза я ловил неслабые.
Но терь на Git'е я по сетке беру коммиты прямо из источника, минуя wget&patch,
а кроме того не ловлю тормоза при локальных (своих) коммитах и просмотре истории (!!), все лежит уже у меня. При необходимости в 2 команды создается отдельная ветка разработки, где можно попробовать че-нить експериментального. Все так же легко получяя коммиты от авторити _и_ из своей изначальной (да и любых других) ветки, а потом точно тем же методом смержить изменения експериментальной в свою основную.
Заметьте, для этого я не подымал никаких сервисов и не выходил за пределы _одной_ директории с деревом пректа...Вобщем, даже сравнивать такое тяжело со старичком свном.
>не надо думать
>надо у Ника спросить.Так несколько раз спросил, а в ответ "ФС (ext3, Dual Opteron 246 2GHz, 3ware 9550SX raid5)." :)))) - клевый транспорт!
Вот и возникают сомнения.
>Так несколько раз спросил, а в ответ "ФС (ext3, Dual Opteron 246
>2GHz, 3ware 9550SX raid5)." :)))) - клевый транспорт!
>Вот и возникают сомнения."не знаю как у вас...", но у нас "транспорт - ФС" - есть четкое понимание протокола передачи :)
>"не знаю как у вас...", но у нас "транспорт - ФС" -
>есть четкое понимание протокола передачи :)ессьно, говоря о системах контроля версий :)
>Ну и как удалось нейтрализовать "влияние сети и другой системы" ???? Или
>все же через httpd долбились - на каждый файл по десяток
>запросов????какое хттп??
вылезайте из пещеры пожалуйста.
Да ни вжизни будь на то моя воля не насетаплю я этих костылей вместо родного протокола хоть svn'а, хоть git'а. И ессьно, поверх ssh (если уж мы рассматриваем сетевой репозиторий).>вот попробуйте разные транспорты, тогда и можете сказать о скорости.
>
>Или вы не в курсе что svn может работать по разному??? И
>с разной скоростью??ой да пасиба. На самом деле даже неважно с какой скоростью SVN _не_ сможет делать элементарные форки и объединения проектов. А без далеко не всякая разработка (хоть и не вся) не достигнет оптимума в скорости. Примеры все те же: wine (раз в 2 недели релиз), ядро Линух, дистр Убунта - все эти товарищи пользуют децентрализованные системы контроля.
Я _знаю_ почему они это делают и _видел_ своими глазами в _своих_ проектах почему крайне затруднительно контролировать версии цетралицованным инструментом.Вот Михаил бросил неплохую сцылку, просмотрите, не пожалейте 10 минут:
http://www.infoq.com/articles/dvcs-guideвсе-таки время не стоит на месте. Может, где-то что-то вам приглянется.
>[оверквотинг удален]
>>А что было сервером httpd или svnserve ???
>>Если через httpd - то чему удивляться ? он сам тормоз.
>
>сервером была ФС (ext3, Dual Opteron 246 2GHz, 3ware 9550SX raid5).
>
>Но столько времени занимал коммит всего ядра, а не мажорного патча (подзабыл,
>давно дело было ;)
>
>вот берем тарбол, растариваем "... add" и "... ci" и на наццать
>минут идем гулять.svn import и svn co не быстрее были бы, раз репозиторий у вас всё равно на локальном диске? Про двойное копирование по сети можно не беспокоиться.
>Это НЕ работа с исходниками масштабов ядра. И Торвальдс это четко по-русски
>:) в
>своем выступлении сказал.
да, речь не о сети вообще. А просто об оптимальности процессов проверки, контроля, хранения...
Достаточно поверхностное сравнение. В сети встречал более глубокое исследование, хотя как пример, не лишено интереса.- Ни слова, напрмер что такое pack/gc. Сколько оно жрёт времени, какой объём до/после.
- Мерять repo initialization это вообще круто :)
Используем mercurial и все доволны.
Разница в производительности для проектов с которыми я работаю(сравнительно небольшие-средние) никакой роли не играет, везде всё происходит моментально.
Даже для таких больших проектов как ядро линукс разница не такая большая.
аналогично
Поддержу.
Лучше бы сделали сравнили возможности. Сам работаю только с svn и mercurial. Интересно узнать особенности других средств
> Интересно узнать особенности других средствА вот в Plan9 из Bell Labs весь центральный файловый сервер превращён в один большой репозиторий:
" ...У файлового сервера три уровня хранения. Центральный сервер в нашей инсталляции имеет буферную память объемом около 100 Мбайт, магнитный диск емкостью 27 Гбайт и дисковод с автоматической сменой WORM-дисков общей емкостью 350 Гбайт как основной накопитель...
...Каждое утро в 5 часов автоматически происходит дамп файловой системы. Система замораживается, и все блоки, модифицированные со времени последнего дампа, становятся в очередь для записи на WORM. После этого служба восстанавливается, и в иерархии всех дампов, когда-либо проведенных, появляется корневой каталог выведенной файловой системы с атрибутом "только для чтения", названный по дате создания. Например, каталог /n/dump/1995/0315 — корневой для образа файловой системы в том виде, каком он был на раннее утро 15 марта 1995 года...."http://cylib.iit.nau.edu.ua/Mirrors/ask.km.ru/plan9/doc/9.html
И вместо svn diff юзаеца обычный diff - и не требуется плодить одинаковые однообразные сущности.
>И вместо svn diffКакой svn diff... Андрей, Вы хоть и являетесь безусловно троглодитом -- но вылазьте иногда из пещеры, на дворе давно DSCM. Притом тот же git diff куда удобнее "обычного diff".
Очень хорошо путать тёплое с мягким. Жизнь сразу становится весёлой и насыщенной.
Было бы любопытно ещё и monotone в сравнении глянуть - вроде как он идеологически достаточно близок к git