Hey! Woah! git conversion!!

[Matthias Andree]

Am 25.05.19 um 23:51 schrieb Steffen Nurpmeso:
> It is not that much here now too, i have relatively recently
> stepped an entire decade of hardware development... and ran
> directly into MDS and now running with four not eight due to
> disabled hyperhyper dingsbums.  And it is all a lie here i guess,
> with 8th generation i5, they say they can scale 400-3400 MHz, but
> with HT disabled they won't run with less than about ~730.
> Nonetheless great.  On CRUX-Linux 3.5, with a <2s boot time!

AMD claims to be unaffected by MDS... whatever.  I don't care too much
for boot time and am spoiling I/O throughput somewhat by LUKS... I am
not monitoring frequencies, my PC is rather power hungry (~50 W idle
power, way too much in my book) but it turned out that going for AMD in
Early 2018 wasn't the worst choice, getting the Ryzen board stable took
2 - 3 BIOS updates and I think I still need to change one setting from
low-current idle whatever to typical current idle so the computer
doesn't freeze when it gets bored.

> What really rocks me is NVME.  That beast scrubs 80 GB of data in
> about 45 seconds, which is >400% of the old MacBook Air SSD!
> *Unbelievable*!

At the time I chose a SATA SSD because NVME was prohibitively
expensive... 431 MB/s raw read speed is good enough for me. Never
checked IOPS, it's so much faster than a 7200/min spinning platter HDD I
didn't really care if it was two or four orders of magnitude.

> What is ample RAM, by the way?

32 GiB. 'nuff for a VM or two and Firefox with
I-don't-care-to-close-my-tabs. ;-)

> The thing is or was that an old git tooks its time but could GC my
> FreeBSD repo, but then they must have changed something and then
> it was plain impossible, regardless of all windowMemory settings.

The FreeBSD repo is surely orders of magnitude bigger than the
bogofilter repo, and probably has way more objects.

I have also precompressed the bogofilter repo with "reposurgeon"'s "make
gc"-equivalent settings so the initial pack download is only 8 MB, and
it appears that it's using bigger search windows than "git gc
--aggressive" would. Not sure but I suppose that helps "git gc" a bit.

>  |The server-side SVN was some 107 MB, the checkout created a .svn dir shy
>  |of 8 MB, virtually no history (that's kept server-side) - that was for
>  |the trunk, not all branches of the repo included, as you'd get with Git.
>
> Hm, fat.  I do not remember SVN that well.  (I had never checked
> that out..)  They once switched their DB backend, and then there
> were an immense number of files, which was an absolute no-go on my
> 3600 rpm disk, so i turned back to CVS for a while, before going
> to git (over short-time mercurial), then.

When SVN was new, it had some advantages over CVS (atomic multi-file
commits, somewhat more concise branching), but was quickly surpassed by
Mercurial (Hg) and Git, and I'd also played with DARCS.net (a
Haskell-based DVCS, for leafnode-2) some years ago. bogofilter's repo,
being through two conversions (CVS at first, then SVN for many years,
and now Git), still shows some of the CVS idiosyncrasies in what I kept
as unlabeled_cvs_branches/unlabeled-* branches, and there are also
plenty of tags that date back to the times when you needed to manually
track what people would call "topic branches" or "feature branches"
these days. The SVN server-side stuff had different repo formats, "fsfs"
the "bunch of files", Berkeley DB, and I know from the earlier
bogofilter days that Berkeley DB driven databases need some attention in
operation so as not to get corrupted.