The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Сравнение производительности Bazaar, git и Mercurial. Рост объема Linux ядра.

10.05.2008 23:22

Доступны результаты сравнения производительности систем управления исходными текстами 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);
  • Получение статуса о состоянии репозитория, без предшествующих изменений: git (1.230s), bzr (4.027s), hg (1.077s);
  • Коммит простейших изменений: git (0.397s), bzr (9.010s), hg (1.913s);
  • Размер репозитория:
    • git (gc): 92 MB;
    • bzr (pack): 112 MB;
    • hg: 179 MB.

В заметке "git/bzr historical performance comparison" представлены результаты похожего сравнения git и Bazaar, но только в контексте оценки прогресса развития новых версий (git 1.5.4.3, bzr 1.3.1) по сравнению со старыми (git 0.99.9c, bzr 0.7pre).

Кроме того, можно отметить интересную статистику роста объема исходных текстов Linux ядра:
Версия Дата выпуска Число строк Размер, Мб
0.01 Sep 1991 10239 0.2
0.10 Dec 1991 17750 0.4
0.99 Dec 1992 81091 2.2
1.0.0 Mar 1994 176250 4.7
1.2.0 Mar 1995 310950 8.4
2.0.0 Jun 1996 777956 22
2.2.0 Jan 1999 1800847 52
2.4.0 Jan 2001 3377902 100
2.5.37 Sep 2002 5100081 152
2.6.0 Dec 2003 5929913 175
2.6.10 Dec 2004 6495542 191
2.6.12 Jun 2005 6777860 199
2.6.18 Sep 2006 7752846 224


  1. Главная ссылка к новости (http://laserjock.wordpress.com...)
  2. OpenNews: Создатели Ubuntu представили новую систему управления версиями
  3. OpenNews: Релиз распределённой системы управления исходным кодом Mercurial 1.0
Лицензия: CC-BY
Тип: Интересно / Практикум
Короткая ссылка: https://opennet.ru/15803-cvs
Ключевые слова: cvs, linux, kernel, git, mercural, bazaar
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (60) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Nick (??), 23:59, 10/05/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Да...
    Торвальдс реально силен :)

    Такую вещь написал!

     
     
  • 2.2, Аноним (2), 00:06, 11/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Несложно победить унылое говно на питоне. Надо было сравнивать с SVN
     
     
  • 3.8, Nick (??), 01:42, 11/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Несложно победить унылое говно на питоне. Надо было сравнивать с SVN

    ой, лучше не надо... Ато после такого сравнения еще больше проектов перейдут с SVN'а на Git.

    Сам около года пользовал SVN для всего и вся. Как асилил Git - прозрение было неслабым.
    Времени на SVN было убито немало....  он тормоз :)

    Git - реально сильная вещь.

     
  • 3.32, iamthegoodbot (?), 13:15, 11/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Несложно победить унылое говно на питоне. Надо было сравнивать с SVN

    а этим еще кто-то пользуется?

     
     
  • 4.34, Nick (??), 13:20, 11/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >>Несложно победить унылое говно на питоне. Надо было сравнивать с SVN
    >
    >а этим еще кто-то пользуется?

    5 %)

     
  • 3.41, Fennel (?), 18:49, 11/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Несложно победить унылое говно на питоне. Надо было сравнивать с SVN

    простите.. где вы увидели питон? подавляющая часть GIT написана на C.

     
     
  • 4.51, h (?), 00:39, 12/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    он имел в виду mercurial, а не git
     
     
  • 5.61, Holy Cheater (?), 17:56, 13/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    имел ввиду он bzr, а не mercurial, и не git.
    В Bzr, в общем-то, скорость - не основное направление.
     
  • 2.4, Аноним (2), 00:34, 11/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    а чего git Линус написал? хм я думал он тока ядро ковыряет :)
     
     
  • 3.5, Аноним (2), 00:40, 11/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >а чего git Линус написал? хм я думал он тока ядро ковыряет
    >:)

    По крайней мере начал, а там уже и другие разработчики допиливали.

     
  • 3.9, Nick (??), 01:44, 11/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >а чего git Линус написал? хм я думал он тока ядро ковыряет
    >:)

    чтоб эффективно его и продолжать писать - он себе сделал инструмент.

     
  • 3.39, Аноним (2), 17:04, 11/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >а чего git Линус написал? хм я думал он тока ядро ковыряет
    >:)

    Линус очень долго пользовался закрытой программой для тех же целей BitKeeper. Получалось что вроде бы linux - флагман свободных программ, а самый главный инструмент - закрыт. Очень долго Линуса пинали за это, но он отшучивался и отмахивался. Главная отмазка была - нет подобных средств, и точка. Насколько я понимаю, ему очень нужна была фича BitKeeper и git по rebase и нормальное merge с учетом всей предыстории.

    Время шло, нападки на Линуса были чаще и сильнее, и тут подвернулся повод - разработчик BitKeeper'a что то там снова решил поменять в лицензии. В итоге Линус не выдержал, и написал GIT.

     
     
  • 4.42, Nick (??), 18:52, 11/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Практически не соврал :)

    Не, все на месте вроде бы.

     
  • 4.45, Michael Shigorin (ok), 21:49, 11/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Время шло, нападки на Линуса были чаще и сильнее, и тут подвернулся
    >повод - разработчик 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-version-control-illu

     

  • 1.3, pavlinux (ok), 00:32, 11/05/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    2.6.25.3 10 May 2008 311M  
     
     
  • 2.6, pavlinux (ok), 00:42, 11/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Упс, строки забыл...

    Лень проверять, но помоему вот так должно заработать:
    # 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 строк

     
     
  • 3.16, mahoro (??), 04:23, 11/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Любишь сложности :)

    Почему не find ... | xargs cat | wc ?

     
     
  • 4.17, pavlinux (ok), 04:37, 11/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Любишь сложности :)
    >
    >Почему не find ... | xargs cat | wc ?

    САТу может и бинарник попасться, тогда уж через strings. (а если честно, не думал, последующий конвейер сам, походу, придумывается)  :)



     
  • 3.46, Michael Shigorin (ok), 21:50, 11/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Упс, строки забыл...

    Лучше sloccount, imho.

     

  • 1.7, pavlinux (ok), 00:48, 11/05/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Сразу и не фтыкнул - оригинал называет "Linux Kernel Growth: 0.01-to-2.6.18 (1991-2006)"

    А чё они до 05.2008  НИАСИЛИЛИ....

     
  • 1.10, szh (ok), 01:55, 11/05/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    обьясняется почему SVN и GIT в разных весовых категориях.

    Linus Torvalds on git:
    http://www.youtube.com/watch?v=4XpnKHJAok8

     
     
  • 2.11, Nick (??), 02:02, 11/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >обьясняется почему SVN и GIT в разных весовых категориях.
    >Linus Torvalds on git:
    >http://www.youtube.com/watch?v=4XpnKHJAok8

    угу, смотрели.

    Но сути не меняет. Git полностью покрывает функционал SVN'а (в том числе и серверная эмуляция оного), а еще Git и более производителен.

    Выбор очевиден.

     
     
  • 3.47, Michael Shigorin (ok), 21:52, 11/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Но сути не меняет. Git полностью покрывает функционал SVN'а (в том числе
    >и серверная эмуляция оного), а еще Git и более производителен.
    >Выбор очевиден.

    Для нас с Вами -- угу, а вот для виндузятников и ынтерпрайза не совсем так: первым важна доступность инструмента и интеграции с IDE на виндах, вторым -- дубовость SVN (в том же плане, что и жабы -- чтоб кодеры ходили предсказуемым строем) и killer app по имени trac ;-)

     
  • 3.18, szh (ok), 05:46, 11/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Детишки это вы. А Линусу было на чем потренироватся и обдумать как все должно работать, перед началом разработки git.

    > а потом плакались что народ пишет её опенсорс аналог
    > (по-моему последнее - это как раз git).

    Нет не git

    > Собственно, вопрос - где эти недоучки сейчас?

    Полагаю там же где и были и занимаются тем же.

     

  • 1.14, User294 (ok), 04:05, 11/05/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    ИМХО: если такая штука как линукс кернель засовывается за считанные секунды, то разница в 5 раз погоды не делает.То есть оно круто но если оно на практике столь большой проект за максимум десятки секунд разруливает - можно выбирать любой манагер версий и не греть мозг этим вопросом, взяв за критерии что-то более важное чем считанные секунды задержек на проекте уровня линуксного кернеля :)
     
     
  • 2.15, Nick (??), 04:18, 11/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >ИМХО: если такая штука как линукс кернель засовывается за считанные секунды, то
    >разница в 5 раз погоды не делает.То есть оно круто но
    >если оно на практике столь большой проект за максимум десятки секунд
    >разруливает - можно выбирать любой манагер версий и не греть мозг
    >этим вопросом, взяв за критерии что-то более важное чем считанные секунды
    >задержек на проекте уровня линуксного кернеля :)

    если.

    Я юзал SVN для управления сырцами ядра с год. Мажорный патч с версии на версию (например 2.6.20 -> 2.6.21) занимало закоммиттить 20 минут...

    Git же за пару десятков секунд сделает это, да еще и без необходимости руками качать дифф, распаковывать и патчить проект. "git pull" + ~20-30 секунд = новая версия.
    Это не идет ни в какое сравнение с геммором SVN, хоть и немалую (но не главную) роль тут играл сам факт хранения ядра в Git'е.

     
     
  • 3.19, geekkoo (??), 10:59, 11/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >>Это не идет ни в какое сравнение с геммором SVN, хоть и немалую (но не главную) роль тут играл сам факт хранения ядра в Git'е.

    По моему, как раз главную. Тормоза связаны именно с тем, что при парсинге diff-а нужно протоколировать это в истории локальных изменений. Понятно, что для Git-а это не требуется (поскольку рабочая версия просто up-to-date).

    Ну, и правило буравчика таково - какой CVS использует проект, над которыми работаете, то ту же VСS используете и вы. Чтоб потом не появлялись рассказы о страшных тормозах той или иной VСS...

     
     
  • 4.48, Michael Shigorin (ok), 21:54, 11/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Ну, и правило буравчика таково - какой CVS использует проект, над которыми
    >работаете, то ту же VСS используете и вы. Чтоб потом не
    >появлялись рассказы о страшных тормозах той или иной VСS...

    Следуя этой рекомендации, можно появить ещё не один рассказ про тормоза Bazaar или SVN :)

     
  • 3.24, fi (ok), 12:00, 11/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Я юзал SVN для управления сырцами ядра с год. Мажорный патч с версии на версию (например 2.6.20 -> 2.6.21) занимало закоммиттить 20 минут...

    А что было сервером - httpd или svnserve ???
    Если через httpd - то чему удивляться ? он сам тормоз.

     
     
  • 4.25, Nick (??), 12:11, 11/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >>Я юзал SVN для управления сырцами ядра с год. Мажорный патч с версии на версию (например 2.6.20 -> 2.6.21) занимало закоммиттить 20 минут...
    >
    >А что было сервером httpd или svnserve ???
    >Если через httpd - то чему удивляться ? он сам тормоз.

    сервером была ФС (ext3, Dual Opteron 246 2GHz, 3ware 9550SX raid5).

    Но столько времени занимал коммит всего ядра, а не мажорного патча (подзабыл, давно дело было ;)

    вот берем тарбол, растариваем "... add" и "... ci" и на наццать минут идем гулять.
    Это НЕ работа с исходниками масштабов ядра. И Торвальдс это четко по-русски :) в
    своем выступлении сказал.

     
     
  • 5.26, Nick (??), 12:21, 11/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    щас попробовал Git'ом это же сделать.

    # wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.25.3.tar.bz2
    # 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

    Согласитесь, достаточно быстро.

     
     
  • 6.28, Nick (??), 12:34, 11/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    собираю svn. как тока так и запосчу результаты.
    все же лучше перепроверить ;)
    ибо мнооого воды утекло :)
    не хотелось бы отстаивать ошибочную точку зрения :)
     
     
  • 7.33, Nick (??), 13:19, 11/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Собсно:

    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'а %))].

     
     
  • 8.35, geekkoo (??), 14:43, 11/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    gt оверквотинг удален Есть специальная команда svn import tar xjvf linux-2 4 ... текст свёрнут, показать
     
     
  • 9.36, Nick (??), 15:01, 11/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    хм неплохо Ессьно, чувствуется, что при том долгом коммите svn занимается п... текст свёрнут, показать
     
     
  • 10.37, geekkoo (??), 15:14, 11/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    gt оверквотинг удален Держать единый репозиторий, и прочие плюшки связанные с ... текст свёрнут, показать
     
     
  • 11.38, Nick (??), 15:25, 11/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, вот посмотрите http git kernel org новые репозитории заводятся крайне прос... большой текст свёрнут, показать
     
  • 9.44, anonymous (??), 21:05, 11/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    gt оверквотинг удален tar xjvf linux-2 6 25 3 tar bz2 mkdir -p r l-2431 svn... текст свёрнут, показать
     
  • 8.43, anonymous (??), 20:52, 11/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    gt оверквотинг удален tar xjf linux-2 6 25 3 tar bz2 cd linux-2 6 25 3 mkdir ... текст свёрнут, показать
     
     
  • 9.53, Nick (??), 07:41, 12/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    А теперь с гитом сравни у себя ... текст свёрнут, показать
     
  • 5.27, fi (ok), 12:34, 11/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >>А что было сервером httpd или svnserve ???
    >>Если через httpd - то чему удивляться ? он сам тормоз.
    >
    >сервером была ФС (ext3, Dual Opteron 246 2GHz, 3ware 9550SX raid5).

    А это тут при чем?????  

    Речь идет о том, какой сервер (прога!!!) был использован в качестве репозитария -свой (svnserve) или httpd с mod_dav_svn? В случаи httpd ни о какой скорости речь не может идти, но зато очень удобно ходить через всякие блокирующие прокси.  

     
     
  • 6.30, Nick (??), 12:38, 11/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    какие прокси, мил человек?...

    Речь о производительности даже на локальной ФС. Нейтрализуя влияние сети и другой системы.
    Просто с винта тут же на него коммитить. Лично мне так было нужно, потому как я ни с кем не разделял эту работу. Мне нужен был всего-лишь контроль версий.

     
     
  • 7.50, fi (ok), 00:17, 12/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >какие прокси, мил человек?...

    Например squid :)))))  но в  вашем случаи он ни причем.

    >Речь о производительности даже на локальной ФС. Нейтрализуя влияние сети и другой
    >системы.

    Ну и как удалось нейтрализовать "влияние сети и другой системы" ???? Или все же через httpd долбились - на каждый файл по десяток запросов????

    вот попробуйте разные транспорты, тогда и можете сказать о скорости.

    Или вы не в курсе что svn может работать по разному??? И с разной скоростью??
      

     
     
  • 8.52, geekkoo (??), 07:08, 12/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Не тупи Когда репозиторий находится на file , то svn работает без сервера Н... текст свёрнут, показать
     
     
  • 9.54, fi (ok), 07:42, 12/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Не тупи С чего ты взял что был file У меня с ним летает Я думаю та... текст свёрнут, показать
     
     
  • 10.56, Nick (??), 08:48, 12/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    не надо думать надо у Ника спросить А было все просто я брал тарболы на кернел... текст свёрнут, показать
     
     
  • 11.57, fi (ok), 11:43, 12/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Так несколько раз спросил, а в ответ ФС ext3, Dual Opteron 246 2GHz, 3ware 955... текст свёрнут, показать
     
     
  • 12.58, Nick (??), 12:07, 12/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    не знаю как у вас , но у нас транспорт - ФС - есть четкое понимание проток... текст свёрнут, показать
     
     
  • 13.60, Nick (??), 12:22, 12/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    ессьно, говоря о системах контроля версий ... текст свёрнут, показать
     
  • 8.55, Nick (??), 08:32, 12/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    какое хттп вылезайте из пещеры пожалуйста Да ни вжизни будь на то моя воля не... текст свёрнут, показать
     
  • 5.29, geekkoo (??), 12:38, 11/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    >>А что было сервером httpd или svnserve ???
    >>Если через httpd - то чему удивляться ? он сам тормоз.
    >
    >сервером была ФС (ext3, Dual Opteron 246 2GHz, 3ware 9550SX raid5).
    >
    >Но столько времени занимал коммит всего ядра, а не мажорного патча (подзабыл,
    >давно дело было ;)
    >
    >вот берем тарбол, растариваем "... add" и "... ci" и на наццать
    >минут идем гулять.

    svn import и svn co не быстрее были бы, раз репозиторий у вас всё равно на локальном диске? Про двойное копирование по сети можно не беспокоиться.
    >Это НЕ работа с исходниками масштабов ядра. И Торвальдс это четко по-русски
    >:) в
    >своем выступлении сказал.

     
     
  • 6.31, Nick (??), 12:40, 11/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    да, речь не о сети вообще. А просто об оптимальности процессов проверки, контроля, хранения...
     

  • 1.20, Константин (??), 10:59, 11/05/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Достаточно поверхностное сравнение. В сети встречал более глубокое исследование, хотя как пример, не лишено интереса.

    - Ни слова, напрмер что такое pack/gc. Сколько оно жрёт времени, какой объём до/после.
    - Мерять repo initialization это вообще круто :)

     
  • 1.40, pawnhearts (ok), 18:08, 11/05/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Используем mercurial и все доволны.
    Разница в производительности для проектов с которыми я работаю(сравнительно небольшие-средние) никакой роли не играет, везде всё происходит моментально.
    Даже для таких больших проектов как ядро линукс разница не такая большая.
     
     
  • 2.49, V (??), 22:25, 11/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    аналогично
     
  • 2.59, nikolaos (?), 12:08, 12/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Поддержу.
    Лучше бы сделали сравнили возможности. Сам работаю только с svn и mercurial. Интересно узнать особенности других средств
     
     
  • 3.64, andr.mobi (??), 01:13, 27/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    > Интересно узнать особенности других средств

    А вот в 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 - и не требуется плодить одинаковые однообразные сущности.

     
     
  • 4.65, Michael Shigorin (ok), 17:57, 28/05/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >И вместо svn diff

    Какой svn diff... Андрей, Вы хоть и являетесь безусловно троглодитом -- но вылазьте иногда из пещеры, на дворе давно DSCM.  Притом тот же git diff куда удобнее "обычного diff".

     
  • 4.66, Zert (??), 07:07, 09/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Очень хорошо путать тёплое с мягким. Жизнь сразу становится весёлой и насыщенной.
     

  • 1.62, гость (?), 00:15, 14/05/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Было бы любопытно ещё и monotone в сравнении глянуть - вроде как он идеологически достаточно близок к git
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру