» FreeArc (часть 4)

http://freearc.org/download/testing/fazip02.zip

FAZip 0.2:


исправлена ошибка: программа возвращала код ошибки -9 при распаковке цепочек методов, например rep+tor
значительно ускорен REP благодаря идее Жени Шелвина
REP получил новый параметр :c, означающий размер хешируемых блоков. Для
:l512 по умолчанию :c128, для :l511..257 по умолчанию :c256 и т.д.
по умолчанию размер хеш-таблицы для REP равен min(:b/:c*4,:b/4)


Бенчмарки:

1. Сжатие с rep:1g
старый REP: 4,531,060,447 -> 3,046,406,598: 67.23% Cpu 364 mb/s (11.872 sec), real 333 mb/s (12.989 sec) = 91%
новый REP: 4,531,060,447 -> 3,064,484,898: 67.63% Cpu 529 mb/s (8.174 sec), real 1341 mb/s (3.221 sec) = 254%

2. Сжатие с rep:1g+xtor:3
старый REP: 4,531,060,447 -> 1,283,663,780: 28.33% Cpu 105 mb/s (41.137 sec), real 270 mb/s (16.026 sec) = 257%
новый REP: 4,531,060,447 -> 1,286,102,352: 28.38% Cpu 87 mb/s (49.671 sec), real 581 mb/s (7.443 sec) = 667%

Для сравнения чистый 4x4:tor:3
4,531,060,447 -> 1,698,510,452: 37.49% Cpu 83 mb/s (52.260 sec), real 586 mb/s (7.380 sec) = 708%

Т.е. теперь не будет потерь в скорости -m1 от добавления REP, при этом сжатие с REP выше в 1.32 раза





fixed bug: error -9 was reported when decompressing files with methods like rep+tor
improved speed of REP using Eugene Shelwien's idea
REP has new parameter :c denoting hashed chunk size. For :l512 default is :c128, for :l511..257 default is :c256 and so on
Default hash size for REP is min(:b/:c*4,:b/4)


Some benchmarks:

1. Compression with rep:1g:513
old REP: 4,531,060,447 -> 3,046,406,598: 67.23% Cpu 364 mb/s (11.872 sec), real 333 mb/s (12.989 sec) = 91%
new REP: 4,531,060,447 -> 3,064,484,898: 67.63% Cpu 529 mb/s (8.174 sec), real 1341 mb/s (3.221 sec) = 254%

2. Compression with rep:1g:513+4x4:tor:3
old REP: 4,531,060,447 -> 1,283,663,780: 28.33% Cpu 105 mb/s (41.137 sec), real 270 mb/s (16.026 sec) = 257%
new REP: 4,531,060,447 -> 1,286,102,352: 28.38% Cpu 87 mb/s (49.671 sec), real 581 mb/s (7.443 sec) = 667%

For comparison, pure 4x4:tor:3
4,531,060,447 -> 1,698,510,452: 37.49% Cpu 83 mb/s (52.260 sec), real 586 mb/s (7.380 sec) = 708%

It means that now REP may be added to the FreeArc -m1 compression method without losing even bit of speed, while compression becomes (in this case) 1.38x tighter

Bulat_Ziganshin

Обращаю внимание на 2 вещи, связанные с новым rep-ом и сжатием Rep+tor:3

На маленьких объемах данных типична такая ситуация:
Метод Размер Время, с

Bulat_Ziganshin

Цитата:

FAZip 0.2:

в rep были изменения относительно rep новый2 от 14.01.12?

Цитата:

Чего я не понимаю?

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

Добавлено:
egor23
я только исправил одну ошибку. как ни странно, это даже чуть ухудшило характеристики программы

Добавлено:

Цитата:

На разных компьютерах, при разном соотношении скорости процессора и устройств ввода/вывода (винт) различие межу методами rep:1g+xtor:3:4m:h128k и rep:1g+xtor:6:4m:h1m:l2 во времени сжатия может быть больше или, наоборот, отсутствовать! Но смысл останется - на больших объемах нет смысла применять  rep:1g+xtor:3:4m:h128k!

C:\Testing\rep\017>fazip rep:1g:c256:256+4x4:tor:6:4m:h1m:l2 D:\Testing\dll4g.dll nul
100%: 4,531,060,447 -> 1,161,045,257: 25.62% Cpu 39 mb/s (109.981 sec), real 292 mb/s (14.821 sec) = 742%

C:\Testing\rep\017>fazip rep:1g:c256:256+4x4:tor:3:4m:h128k D:\Testing\dll4g.dll nul
100%: 4,531,060,447 -> 1,278,123,155: 28.21% Cpu 90 mb/s (48.204 sec), real 608 mb/s (7.103 sec) = 679%

Я не знаю, что такое fazip.


Добавлено:
Он же не пишет на винт, а отправляет в nul?
Какое это отношение имеет к сжатию данных в реальных условиях?

Добавлено:
Загрузка CPU - это только часть процесса. И для быстрых методов не самая большая часть.

Добавлено:

Цитата:

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

Так я делаю.
Но не получается взять целиком Excel-евскую или Word-овскую табличку и вставить. Только по одной ячейке. Застрелиться можно.

Цитата:

Но не получается взять целиком Excel-евскую или Word-овскую табличку и вставить. Только по одной ячейке. Застрелиться можно.

Может пригодится http://theenemy.dk/table/

Цитата:

Он же не пишет на винт, а отправляет в nul?
Какое это отношение имеет к сжатию данных в реальных условиях?  

а ты не думаешь, что на других машинах соотношение скорости диска и процессора может на порядок отличаться от твоего?

Bulat_Ziganshin
Булат, добрый день. А Вы не планируете добавить Оценку Сжатия, как в HaoZIP и поддержку ASCII-комментов, как в WinRAR?

Добавлено:
Отлично я написал.."Добрый день" в 03:31))

Bulat_Ziganshin

Цитата:

а ты не думаешь, что на других машинах соотношение скорости диска и процессора может на порядок отличаться от твоего?

Гипотетически - конечно, да!
То есть это для таких случаев, если они есть?
(для этого нужен какой-нибудь райд, но ведь и проц будет не моего уровня).


Добавлено:
А почему вообще такое происходит - на небольшом объеме данных tor:3 в разы превосходит по скорости, а на больших объемах чуть-чуть (на одном и том же компьютере)?
Что в принципе творится?

Добавлено:
slech

Спасибо, попробую.

Приветствую.
Подскажите пожалуйта,какой алгоритм сжатия лучше подойдет для сжатия файлов мультимедиа?

Bulat_Ziganshin
Потестировал я ещё раз свои файлики - к сожалению, при использовании -mx и при отключенных некоторые прекомпрессорах, ошибки всё равно иногда появляются - если же использовать -m9, то архивы создаются без проблем.

Bulat_Ziganshin

1. Понял про разницу во времени маленьких объемов и больших.
При маленьких объемах, похоже, исходные данные хранятся в ОЗУ, и на диск идет только запись. (Я ведь несколько раз подяд прогоняю сжатие).
При больших объемах, данные реально считываются и записываются. Получается две дисковых операции, скоростные методы преимущество теряют.

2. При новом rep-е появляется еще интересный скоростной вариант: rep+xtor:3:4m:h64k
Один из примеров, везде rep от 11.01.2012:

Без rep-а
FreeArc 0.67 (December 25 2011) Creating archive: proba5.arc using 4x4:tor:3:4mb:h256kb
Memory for compression 83mb, decompression 88mb, cache 16mb
Compressed 1,731 files, 757,517,055 => 527,930,839 bytes. Ratio 69.6% Compression time: cpu 27.11 secs, real 7.44 secs. Speed 101,866 kB/s
FreeArc 0.67 (December 25 2011) Updating archive: proba5.arc using 4x4:tor:3:4mb
Memory for compression 83mb, decompression 88mb, cache 16mb
Compressed 1,731 files, 757,517,055 => 532,685,127 bytes. Ratio 70.3% Compression time: cpu 24.30 secs, real 7.59 secs. Speed 99,825 kB/s

С rep-ом
FreeArc 0.67 (December 25 2011) Creating archive: proba5.arc using rep:1gb+4x4:tor:3:4mb
Memory for compression 1171mb, decompression 1112mb, cache 16mb
Compressed 1,731 files, 757,517,055 => 435,592,914 bytes. Ratio 57.5% Compression time: cpu 24.15 secs, real 6.94 secs. Speed 109,162 kB/s
FreeArc 0.67 (December 25 2011) Creating archive: proba5.arc using rep:1gb+4x4:tor:3:4mb:h64kb
Memory for compression 1170mb, decompression 1112mb, cache 16mb
Compressed 1,731 files, 757,517,055 => 436,406,848 bytes. Ratio 57.6% Compression time: cpu 22.18 secs, real 6.40 secs. Speed 118,429 kB/s

Добавлено:
Внес исправления

Цитата:

Гипотетически - конечно, да!
То есть это для таких случаев, если они есть?
(для этого нужен какой-нибудь райд, но ведь и проц будет не моего уровня).

достаточно ssd и какого-нибудь ультрабучного процессора


Цитата:

Подскажите пожалуйта,какой алгоритм сжатия лучше подойдет для сжатия файлов мультимедиа?

стандартным, fa сам разберётся


Цитата:

Потестировал я ещё раз свои файлики - к сожалению, при использовании -mx и при отключенных некоторые прекомпрессорах, ошибки всё равно иногда появляются - если же использовать -m9, то архивы создаются без проблем.

-mx определяется как -m9, так что вопрос просто в везении. а в чём проблема - в твоей машине иди моей программе, надо разбираться, тестировать сжатие присланных тобой файлов

Цитата:

достаточно ssd

Да, я уже так подумал.

В ближайшее время (завтра?) выложу вчернове линейку равномерных методов (основных) для FreeArc. Вроде получилось.

SREP 3.0 released:-m1f..-m3f: Future-LZ compression; -m3f now is the default mode
-mem: limit amount of RAM used for Future-LZ decompression
-vmfile and -vmblock options fine-tune VM file used in -mem mode
-mBYTES: copy matches longer than BYTES directly from outfile
3x faster compression: I/O and MD5/SHA1 tasks were offloaded into separate thread
unrolled internal loop, unrolling factor controlled by -a option, -a1 is the slowest but requires least memory
-nomd5: don't store/check MD5 checksum of every block
-mmap: use memory-mapped file for match checking by I/O
when necessary, temporary file is created automatically
made stderr always unbuffered (useful for GUIs around srep.exe providing progress indicator)
"srep" and "srep -d" commands now work as a filter if stdin and stdout are redirected
64-bit version now can use >4 GB of RAM
fixed bug when compressing data from pipe (i.e. producer | srep)
Changes since the latest alpha:files compressed with -nomd5 tagged with special flag in the compressed file header, so that -nomd5 is automatically applied on their decompression with appropriate message to user
added date, version, copyright and other exe resources to windows executables
More info at http://freearc.org/research/SREP.aspx


Релиз SREP 3.0:-m1f..-m3f: Future-LZ сжатие; -m3f теперь - режим по умолчанию
-mem: ограничивает объём ОЗУ, используемый для Future-LZ распаковки
-vmfile и -vmblock: опции, настраивающие файл подкачки, используемый при ограничении ОЗУ опцией -mem
-mBYTES: копировать матчи длиннее BYTES байт напрямую из выходного файла
3-кратно ускорена упаковка: I/O и вычисление MD5/SHA1 вынесены в отдельный тред
развёрнут внутренний цикл упаковки, коэф. разворачивания настраивается опцией -a, -a1 - самый медленный режим, но использует чуть меньше памяти
-nomd5: не запоминать/проверять MD5 хеши блоков
-mmap: использовать отображение файлов в память для проверки матчей через I/O
при необходимости временный файл создаётся автоматически (если не указано -temp= без параметра)
stderr никогда не буферизуется (полезно для GUI-программ, выводящих индикатор прогресса для srep.exe)
"srep" и "srep -d": эти команды теперь работают как фильтр, если stdin и stdout перенаправлены
64-битная версия теперь может использовать >4ГБ ОЗУ
исправлена ошибка при сжатии данных, полученных по конвейеру (например, producer | srep)
Изменения с последней альфы:файлы, сжатые с -nomd5, помечаются спецфлагом в заголовке сжатого файла, так что -nomd5 автоматически используется и при их распаковке с выводом соответствующего сообщения пользователю
добавлены дата, версия, копирайт и прочие exe-ресурсы в виндовые exe-файлы
Хотите узнать больше? http://freearc.org/research/SREP.aspx

Eagle1726
Подскажите пожалуйта,какой алгоритм сжатия лучше подойдет для сжатия файлов мультимедиа?
Если эти файлы уже упакованные, то, по идее, от дополнительной компрессии архиватором будет мало пользы. Другое дело — форматы вроде WAV, которые можно сжимать как с потерями данных (англ. "lossy"; например, в формат MP3), так и без потерь (англ. "lossless"; например, в формат FLAC). Без конкретики это, в общем-то, праздный разговор.

Bulat_Ziganshin

Цитата:

-mx определяется как -m9, так что вопрос просто в везении.

Действительно, в везении - вчера упаковывал одну игрушку (я не "репакер" - просто файлики у себя в порядок привожу...) и вылетела ошибка уже с -m9.


Цитата:

а в чём проблема - в твоей машине иди моей программе, надо разбираться, тестировать сжатие присланных тобой файлов

7z и рар архивы создают без проблем.
P.S. Если надо что-то протестировать для решения проблемы, то я всегда готов!

Bulat_Ziganshin
Как и обещал, выложил тест с новой линейкой методов –m81…-m89 здесь:
http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=760#6
Линейка методов имеет примерно равномерный шаг возрастания времени сжатия от метода к методу и составляет 1,4…1,5.
Расшифровка методов:


Добавлено:
Метод Расшифровка метода Примерное соответствие стандартному методу

Shuld
1. твоим результатам по настройке параметров fb и т.п. я не очень доверяю - это может зависеть от типа данных. хотя с другой стороны, я сам это вообще не тестировал, скопировал готовые настройки из однопоточных режимов, оптимизацией которых я занимался ещё на старом cpu

2. предлагаемые тобой методы сжатия требуют много памяти для распаковки, что заставляет задуматься о том, как их можно использовать, не создавая проблем. я разные способы передумал, сейчас склонился к тому, чтобы всё же встроить srep в fa, но пока это дело будущего

3. на настоящий же момент я оптимизировал rep, добавил его в -m1 и оптимизировал настройки rep в -m2..m4 что повысило сжатие на 1-2% без потерь скорости


теперь что касается внедрения srep. произойдёт это в лучшем случае в 0.80. в январе я сделал очень важную вещь - реализовал поддержку методов с несколькими выходными потоками (как bcj2 в 7-zip). srep в fa будет сделан на основе нынешнего режима -m1f, но сжатые данные будут записываться в два потока - поток литералов и поток матчей. литералы будут писаться (и сжиматься дальнейшими exe+delta+lzma) сразу, а матчи копиться в памяти, и по окончании данных сортироваться по src и только затем сохраняться в архив. соответственно, при распаковке я смогу читать данные из обоих потоков параллельно и сохранять в памяти/vmfile содержимое будущих матчей

итого - и при сжатии, и при распаковке чтение и запись данных будет осуществляться чисто последовательно, при этом будет использоваться объём памяти, примерно равный 10% от объёма сжимаемых данных. при необходимости его можно дальше сократить - при упаковке за счёт увеличения -l, при распаковке - за счёт сохранения содержимого матчей во временном файле. помимо этого, можно ещё выцыганить несколько процентов сжатия, используя после srep обычный rep сч небольшим словарям и размером матча, к примеру rep:96m:32


кстати, пример распаковки 100 гб файла (со 100 гб словарём!!!) с использованием всего 100 мб памяти:

D:\>srep64i -d -mem100m m1f.srep nul
100%: 55,214,690,844 -> 98,420,528,640: 56.10%. Cpu 112 mb/s, real 84 mb/s
Matches 0 68925 39805211, I/Os 0, RAM 0/60, VM 0/8808, R/W 221352/221352

Добавлено:
Архиватор Размер словаря

Bulat_Ziganshin
что-то svn не пашет, или он куда-то переместился?

Bulat_Ziganshin, смените на сайте

Цитата:

FreeArc — планы на будущее
Трекер: список планируемых улучшений по версиям
Версия 0.70 (декабрь 2011)
•полная поддержка zip, rar, 7z и других архивных форматов

А то время потерял пытаясь найти 0.70 для скачивания. и версия 0.67 после установки пишет что появилась что-то новое, но по факту скачать можно её-же..

Цитата:

Версия 0.75
•алгоритм сжатия SREP
•поддержка LZMA со словарём до 1 гб

В версии 0.67 в виде экспериментальных опций включены (работают)?

Что-то не могу сохранить настройки через GUI, при повторном заходе чекбоксы и все остальное по дефолту..
p.s. В идиале было бы приятно видеть автоматическое обновление сабжа как это происходит с лисой, хромом, лунаскейпом (браузеры) и другими безплатными программами.

Bulat_Ziganshin

Цитата:

1. твоим результатам по настройке параметров fb и т.п. я не очень доверяю

Для lzma:fast и lzma:normal поведение существенно отличается. В последнем fb заметно влияет на скорость.

Цитата:

2. предлагаемые тобой методы сжатия требуют много памяти для распаковки

их можно использовать и с другими размерами rep. Правда, эффективность упадет...

Я вообще хочу сказать вот что.
Тестируя с одним размером rep-а, разница по сжатию между последущими tor и lzma очень небольшая (в последнем тесте 2%), они по-существу выполняют роль дожатия. Очень много зависит именно от rep-а.
1. Поэтому для быстрых методов (-m1) нужен именно быстрый rep.
2. Для более сильного сжатия нужен rep с оптимизацией не на скорость, а на сжатие (если такое возможно), как полноправный метод
3. Для ультра сжатия возможно вот что.
У меня часто бывает так: скопировал из интернета прорамму/книгу/музыку, распаковал и оставил вместе с архивом. Или, допустим файл word-а запаковал, отправил по e-mail, да и оставил оба экземляра.
Короче: у меня на компьютере часто хранятся архивы и они же, но распакованные. Возможно, у других пользователей то же самое.
Зачем сжимать 2 раза одно и то же?
Можно модифицировать rep так: он распаковывает в доплнительную область ОЗУ (tempfile) все архивы rar, zip, exe (которые попадают в область сжатия), а "простые" файлы в другую область и сравнивает. Если находятся совпадения, данные в "архивном" ОЗУ не трогаются, а в "простом файловом" дается ссылка на соответствующий архив.
Время займет немало, но, возможно увеличит степень сжатия.
Кто-нибудь такое уже реализовывал?

Добавлено:
Или другими словами, все архивы распаковываются, и используются как словарь.

Цитата:

А то время потерял пытаясь найти 0.70 для скачивания.

спасибо, исправил


Цитата:

и версия 0.67 после установки пишет что появилась что-то новое, но по факту скачать можно её-же..

считай, издержки альфы


Цитата:

В версии 0.67 в виде экспериментальных опций включены (работают)?  

нет, я это буду делать после выпуска 0.70


Цитата:

Что-то не могу сохранить настройки через GUI, при повторном заходе чекбоксы и все остальное по дефолту..

в диалоге settings всё сохраняется


Цитата:

p.s. В идиале было бы приятно видеть автоматическое обновление сабжа как это происходит с лисой, хромом,

согласен но тут и так много недовольных задержкой с выходом 0.70

Добавлено:

Цитата:

что-то svn не пашет, или он куда-то переместился?

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


Добавлено:

Цитата:

Тестируя с одним размером rep-а, разница по сжатию между последущими tor и lzma очень небольшая

ты на чём-нибудь кроме своего бэкапа тестировал? вот на первом же нормальном файле:

D:\Testing>fazip 4x4:lzma:8m:fast dll100.dll nul
100%: 100,000,000 -> 31,546,433: 31.55% Cpu 7 mb/s (13.868 sec), real 36 mb/s (2.647 sec) = 524%

D:\Testing>fazip 4x4:tor:8m dll100.dll nul
100%: 100,000,000 -> 36,668,388: 36.67% Cpu 28 mb/s (3.354 sec), real 142 mb/s (0.671 sec) = 500%


Цитата:

Можно модифицировать rep так: он распаковывает в доплнительную область ОЗУ (tempfile) все архивы rar, zip, exe (которые попадают в область сжатия), а "простые" файлы в другую область и сравнивает. Если находятся совпадения, данные в "архивном" ОЗУ не трогаются, а в "простом файловом" дается ссылка на соответствующий архив.

блестящая идея, я лично её раньше не встречал

Цитата:

ты на чём-нибудь кроме своего бэкапа тестировал?

Я не о том.
Я о
rep +tor
rep+lzma
!!!
В том то и дело, что отдельно взятый tor сильно уступает lma, а в связке с rep эта разница становится почти символической.

Shuld
D:\Testing>C:\Testing\rep\017\fazip rep:64+4x4:tor:8m dll100.dll nul
100%: 100,000,000 -> 32,368,300: 32.37% Cpu 28 mb/s (3.448 sec), real 129 mb/s (0.738 sec) = 467%

D:\Testing>C:\Testing\rep\017\fazip rep:64+4x4:lzma:8m:fast dll100.dll nul
100%: 100,000,000 -> 29,434,451: 29.43% Cpu 7 mb/s (14.492 sec), real 43 mb/s (2.236 sec) = 648%

ещё раз - у тебя в бекапах половина уже сжатые данные, их и не сожмёшь ничем после ловли повторов

В первом случае случае (без rep) разница 5%, во втором - вдвое меньше. Вот об этом я говорю.
А если взять rep +xtor:6:4m:h8m?

во-первых, я считаю разницу от размера сжатых данных. далее - сравни:

D:\Testing>C:\Testing\rep\017\fazip rep:64+4x4:tor:6:8m dll100.dll nul
100%: 100,000,000 -> 31,352,957: 31.35% Cpu 18 mb/s (5.288 sec), real 94 mb/s (1.014 sec) = 522%

D:\Testing>C:\Testing\rep\017\fazip rep:64+4x4:lzma:8m:fast dll100.dll nul
100%: 100,000,000 -> 29,434,451: 29.43% Cpu 7 mb/s (14.492 sec), real 43 mb/s (2.236 sec) = 648%

D:\Testing>C:\Testing\rep\017\fazip rep:64+4x4:lzma:normal:8m dll100.dll nul
100%: 100,000,000 -> 27,779,433: 27.78% Cpu 3 mb/s (31.871 sec), real 22 mb/s (4.293 sec) = 742%


как видишь, lzma:fast находится посредине между lzma:normal и tor:6 и по сжатию, и по времени работы, т.е. обеспечивает формирование равномерной линейки методов. в третьих, в tor встроен упрощённый аналог delta, lzma же надо использовать вместе с ним, и тогда разница становится ещё больше:

D:\Testing>C:\Testing\rep\017\fazip rep:64+delta+4x4:tor:6:8m dll100.dll nul
100%: 100,000,000 -> 31,144,107: 31.14% Cpu 18 mb/s (5.179 sec), real 72 mb/s (1.325 sec) = 391%

D:\Testing>C:\Testing\rep\017\fazip rep:64+delta+4x4:lzma:8m:fast dll100.dll nul
100%: 100,000,000 -> 28,523,697: 28.52% Cpu 7 mb/s (13.634 sec), real 40 mb/s (2.357 sec) = 578%

D:\Testing>C:\Testing\rep\017\fazip rep:64+delta+4x4:lzma:normal:8m dll100.dll nul
100%: 100,000,000 -> 26,980,494: 26.98% Cpu 3 mb/s (31.637 sec), real 22 mb/s (4.435 sec) = 713%

Bulat_Ziganshin
Цитата:

тебя не устраивают исходники, которые я публикую с альфа-версиями?

в svn я мог увидеть разницу между предыдущим и следующим билдом прям в проге, которая показывает различия в исходниках между этими двумя билдами. И при этом ты там пишешь более информативные комменты для конкретного фикса, чем указываешь при релизе альфы.

Bulat_Ziganshin


Цитата:

как видишь, lzma:fast находится посредине между lzma:normal и tor:6 и по сжатию, и по времени работы, т.е. обеспечивает формирование равномерной линейки методов

Согласен.
Это и есть примерно мой вариант.

Добавлено:
Только шаг в 2 раза слишком большой

Profrager
согласен. собственно, вопрос был в том, нужно ли это кому-нибудь. раз желающий нашёлся, постараюсь сделать фильтрованный репозиторий hg. можно и svn, но там в любом случае будет более бедное, линейное дерево коммитов


Цитата:

Это и есть примерно мой вариант.

ну да? ты вроде предлагал заменить lzma:fast на tor:6