> для того, чтобы один раз такое сделать - всё время хранить всю
> историю всей системы с 1996 года?Не скажу за HG, а гит это делает столь компактно, что вся история с лохматого ядра 2.6.11 (я даже не помню когда оно вышло) до распоследнего 3.16-rc4 занимает порядка гига в сумме и растет медленно, несколко Мб на релиз. По поводу чего в развернутой иерархии такого калибры, с которой делают что-то осмысленное - основной статьей расхода места на диске как правило является отнюдь не содержимое диры .git. А вот независимо вывалить все ревизии с 2.6.11 до 3.16-rc4 - это да, никакого диска не хватит. Но обычно рабочее дерево всего 1 или как максимум несколько, по этому поводу можно мотаться по 100 версиям отстоящим друг от друга на километр с вполне разумными затратами ресурсов и не перекачивая 100 раз почти все файлы целиком.
Вообще, специалисты по программированию умеют выбирать компактные формы представления и эффективные алгоритмы. Оно хранит только дельту, да еще упакованно. Потому можно хранить 100 ревизий с относительно небольшими затратами места. Не 100х а допустим 2х. Чем-то таким профессионалы от питонистов типа тебя и отличаются.
> тем более, как я вообще узнаю, как что прилетело.
В git есть git log, чтобы посмотреть что и от кого. А если так не понятно откуда гадость прилетела и где замаскировалась - есть bisect. За несколько попыток гадость можно локализовать даже не зная что это было и откуда. Маленькая математическая магия, далеко не новая. Но по прежнему позволяющая красивые фокусы. А вот с CVS/SVN/... такой маневр будет смотреться медленно и печально. И потребует скачать весь интернет 10 раз подряд.
> я использую текущую систему всю, целиком, а если разбираться, где источник
> проблем - тут уже вообще без разницы, какая система версий.
Как раз разница может быть *гигантской*. С гитом можно ткнуться в 10 отстоящих за километр ревизий большого проекта (размером с линевый кернель например), не скачивая весь интернет 10 раз. Это будет просто и быстро и основное время уйдет на, собственно, сборку софта и проверку бажности энной ревизии. А за 10 раз баг, живший в неизвестном месте - загонится в угол. Путем отделения половины жилполщади по критерию "баг тут" или "баг не тут". Очень скоро окажется что багу некуда бежать. А вот с CVS/SVN такой маневр проводить... ээээ.... качать 10 раз почти целиком - задолбаешься. Гит то хранит только дельту, локально и компактно.
> то есть, это, конечно, круто, что я могу вот так вот ВЖИК,
Это не просто круто. Это позволяет найти блоху на теле у слона по быстренькому, путем отсекания по половинке площади с блохой.
> и сделать. Только это мне нафиг не надо. У меня на
> одном компьютере раздел с openbsd 9 гб, на втором - до
> вчерашнего дня был 7.5, теперь 15. и исходники системы, портов, ксенокары
> и веб-сайта у меня всегда при мне.
Не знаю что надо тебе, но по идее, система контроля версий должна прежде всего эти самые версии контролировать, позволяя ненапряжно шариться по десятку разныз ревизий, независимо от расстояния между ними. А все остальные применения для VCS вообще побочны. То что некоторые путают VCS с файлопомойками - бывает, да. В благодарность это нагибает их рабочие процессы, ибо сложно микроскопом гвозди забивать...
