Информация об изменениях

Сообщение Re[16]: Git wtf?.. от 04.02.2016 21:43

Изменено 04.02.2016 21:49 ·

Здравствуйте, alex_public, Вы писали:

_>>>Согласен) Хотя вот тут http://rsdn.ru/forum/flame.comp/6335165.1
Автор: netch80
Дата: 04.02.16
противоположное мнение высказывается. )

_>·>Ну, если более старые DVCS рассматривать, то да. Но накой DVCS hg начала что-то тянуть из centralised VCS типа svn... это не совсем разумное решение. Может в короткой перспективе, перетянуть юзеров, это и хорошо, но лучше в этом болоте не засиживаться.
_>Не, я не про старые DVCS. Там ниже было высказывание, что к CVS и SVN ближе Git, а не Mercurial. )
Там вроде про ветки. Ветки — да, в hg это нечто уникальное, неповторимое понимание, попытка натянуть сову на глобус. Где ещё есть многоголовые ветки?

_>>>Ну возьми просто один большой (скажем на мегабайт, для простоты эксперимента) и кинь его пустой репозиторий. Ну поменяй пару строк и зафиксируй. И посмотри размер хранилища. Для hg и для git.

_>·>Игрушечных экспериментов, которые плохо сработают для hg я могу тоже насочинять. Например, добавить тот же файл дважды в разные каталоги.
_>ОК, давай возьмём просто любой большой проект и кинем его в чистый репозиторий) Причём это ещё будет максимально лояльным для Git тестом, т.к. у него размер существенно растёт именно с числом изменений.
Дело было вечером, делать было нечего. Я взял openssl-1.0.1r.tar.gz, 4.4мб, распаковал 44мб исходников, 2183 файлов, 130 каталогов... Что-то плохо всё с hg:
- git hg
init 0.223 0.714
add 2.801 1.143
commit 0.870 5.327
add+commit 3.671 6.470
size 32 30
gc 5.670 -
size final 5.8 30
Время в секундах, размер в мегабайтах. hg 3.4, git 2.0.3, ubuntu, linux 4.2.0-23.
Очень интересно — размер repacked git репо сравним с tar.gz тех же данных.
Проведи такой же эксперимент — интересно будут такие же результаты или я что-то не так померил...

_>>>Ну а что касается обмена изменениями, то для последних ревизий (где пара строк менялась) разница действительно не принципиальна (типа 100 байт или 200), а вот если взять все ревизии (тогда оно будет включать файлы целиком), то опять же будет весьма интересный результат...

_>·>Эээ.. А как ещё? Если хочется патчи, бери патчи.
_>Не, я не про это. Я про размер получаемого файла (в котором по сути содержится весь репозиторий). Какой он будет у Mercurial, а какой у Git. Тут же утверждали, что низкоуровневая архитектура у Git более продумана и позволяет большее сжатие и т.п. А на практике...
... так и получается.
А вообще, какого файла?.. Если у тебя полная ревизия, то да, будет полный снапшот, если это diff, будет diff. Как это зависит от vcs?

_>>>Согласен. ) И в таком случае выигрывать по размеру хранилища будет скорее Mercurial.

_>·>Будет, но не долго, до первого же repack.
_>Угу и потом ещё пару изменений продержится на минимуме, а потом снова... )))
Может в каких-то ситуациях так и может быть, но обычно с точностью до наоборот.
Здравствуйте, alex_public, Вы писали:

_>>>Согласен) Хотя вот тут http://rsdn.ru/forum/flame.comp/6335165.1
Автор: netch80
Дата: 04.02.16
противоположное мнение высказывается. )

_>·>Ну, если более старые DVCS рассматривать, то да. Но накой DVCS hg начала что-то тянуть из centralised VCS типа svn... это не совсем разумное решение. Может в короткой перспективе, перетянуть юзеров, это и хорошо, но лучше в этом болоте не засиживаться.
_>Не, я не про старые DVCS. Там ниже было высказывание, что к CVS и SVN ближе Git, а не Mercurial. )
Там вроде про ветки. Ветки — да, в hg это нечто уникальное, неповторимое понимание, попытка натянуть сову на глобус. Где ещё есть многоголовые ветки?

_>>>Ну возьми просто один большой (скажем на мегабайт, для простоты эксперимента) и кинь его пустой репозиторий. Ну поменяй пару строк и зафиксируй. И посмотри размер хранилища. Для hg и для git.

_>·>Игрушечных экспериментов, которые плохо сработают для hg я могу тоже насочинять. Например, добавить тот же файл дважды в разные каталоги.
_>ОК, давай возьмём просто любой большой проект и кинем его в чистый репозиторий) Причём это ещё будет максимально лояльным для Git тестом, т.к. у него размер существенно растёт именно с числом изменений.
Дело было вечером, делать было нечего. Я взял openssl-1.0.1r.tar.gz, 4.4мб, распаковал 44мб исходников, 2183 файлов, 130 каталогов... Что-то плохо всё с hg:
[th]init
- git hg hg/git[th]
0.223 0.714
add 2.801 1.143
commit 0.870 5.327
add+commit 3.671 6.470 1.8
size 32 30 0.9
gc 5.670 -
size final 5.8 30 5.2
Время в секундах, размер в мегабайтах. hg 3.4, git 2.0.3, ubuntu, linux 4.2.0-23.
Очень интересно — размер repacked git репо сравним с tar.gz тех же данных.
Проведи такой же эксперимент — интересно будут такие же результаты или я что-то не так померил...

_>>>Ну а что касается обмена изменениями, то для последних ревизий (где пара строк менялась) разница действительно не принципиальна (типа 100 байт или 200), а вот если взять все ревизии (тогда оно будет включать файлы целиком), то опять же будет весьма интересный результат...

_>·>Эээ.. А как ещё? Если хочется патчи, бери патчи.
_>Не, я не про это. Я про размер получаемого файла (в котором по сути содержится весь репозиторий). Какой он будет у Mercurial, а какой у Git. Тут же утверждали, что низкоуровневая архитектура у Git более продумана и позволяет большее сжатие и т.п. А на практике...
... так и получается.
А вообще, какого файла?.. Если у тебя полная ревизия, то да, будет полный снапшот, если это diff, будет diff. Как это зависит от vcs?

_>>>Согласен. ) И в таком случае выигрывать по размеру хранилища будет скорее Mercurial.

_>·>Будет, но не долго, до первого же repack.
_>Угу и потом ещё пару изменений продержится на минимуме, а потом снова... )))
Может в каких-то ситуациях так и может быть, но обычно с точностью до наоборот.