Здравствуйте, 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.
_>Угу и потом ещё пару изменений продержится на минимуме, а потом снова... )))
Может в каких-то ситуациях так и может быть, но обычно с точностью до наоборот.