Quite frankly, I doubt I'm telling anything new here ... Hello,
as likely many other people, I follow the changes in the
security-tracker repository¹, and I noticed it structure is making
things inconventient.
While the size of a checkout is already somewhat big (around 60 Mbyte),
there is one file data/CVE/list with a size of about 55 Mbyte, and it
gets changed several times a day. Now the way git works, each state is
stored in full. So it's little surprise git pull adds 300 to 900 Mbyte
to .git/objects/pack every(!) day.
Perhaps I'm the last person not having grown into the habit of "Why
bother, bandwidth is cheap, storage is cheap" - in my opinion however
this reached a point that is way beyond acceptable. In my checkout,
.git/objects/pack has 28 Gbytes, and given the current rate this will
grow beyond 100 by the end of the year. If you don't follow, try an
initial git clone on a box with 4 Gbyte RAM, connected with 10 Mbit or
less.
Looking into the repository, the solution is so obvious I was wondering
why it hasn't been done yet: Split data/CVE/list by year: All CVE
numbers from 1999 would be in a file data/CVE/list.1999 and so on.
Occasionally you'd have to edit two files, still you'd have to push like
5 MByte, not 55.
What did I miss?
Christoph
¹ https://salsa.debian.org/security-tracker-team/security-tracker
signature.asc
Description: PGP signature
