Size of the security-tracker repository

--AMk9KGQNhVBz10nd
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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=C2=B9, 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,
=2Egit/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

=C2=B9 https://salsa.debian.org/security-tracker-team/security-tracker

--AMk9KGQNhVBz10nd
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEWXMI+726A12MfJXdxCxY61kUkv0FAmohtOUACgkQxCxY61kU
kv27UBAA0hhKNDObgA6XpYQKB9tnfenIp2yAwko2wXjEaheyDD7M5csvu8Ih8RAP
T26nBlHLHU1xwwV07VYM9m02W6n4P1HwXd8npUeziu1KG1hWa1rCZNn0t3TPkjNi
W5RN/tMIS5rUpUrJYpM1q+IbKmkfiP+hoIJDRqCHwcjMmfvO8yxtJ00iU08D2koO
zFzZzfs9cqweAwLBvhRQznedybRoM58QQqrmenHncT7Mi2VwT0TTZBHEODfawgVG
cWCx57DmpfAk4Veu+Y25VdIXLw94bvIgevDT+C+H7fmGgn2byklDrW5gZNz/y4h9
QtVj3iq73PDbOxboB2TPIfGyFcUMo0AiQUB5GW3XoM2WYHdMOG+5IFy+tiJ+15xC
LO7BpBkqLL7Tm6S43RM5P0TAglswL1TeWVDewmlNrEm778Q5P5pkGUtdsw3MCdZL
K/QxsG6eZHB3uumK5d4XOgEDzdxvJiMJqxFtt8pib060W9kwsRICrJUautdDBGJT
dlLFDwXJ171mJG9VdPkYgnIyRbJDjt6nRm/SHrltVOBCimyDgR/pdz1lcb1JKfUS
cNM4urQLonknvmlGJn14kv/sjbEzggie03EN1BkL6BgApOUhbDvg8e0JSo5kYs8z
Dy1+F0mbmM5s1uz1URRtx/x8q6EOF0tN7u15PZIoNheRdvuex68=
=66Nc
-----END PGP SIGNATURE-----

--AMk9KGQNhVBz10nd--