{"push_id":2308881749,"size":3,"distinct_size":3,"ref":"refs/heads/develop","head":"95854555f038708ddb3fe2e7244deaa57e9a4b8c","before":"3b2e51b8f290c9c8511a43a29c80844866a22845","commits":[{"sha":"0a0c197ed487c343675b62dff8456932c8d5ff7f","author":{"name":"Christian Mollekopf","email":"b722e7edb0e857c64003942e3906e2a94832df33@fastmail.fm"},"message":"Dump some process stats on exit in the synchronizer.","distinct":true,"url":"https://api.github.com/repos/KDE/sink/commits/0a0c197ed487c343675b62dff8456932c8d5ff7f"},{"sha":"9b84aff4b68c3cef3328c85ac12418048b169cee","author":{"name":"Christian Mollekopf","email":"b722e7edb0e857c64003942e3906e2a94832df33@fastmail.fm"},"message":"Store all BLOB properties inline.\n\nBLOB properties had a couple of intended purposes:\n* Allow large payloads to be streamed directly to disk, and then be\nhandled by reference.\n* Allow zero-copy handling.\n* Keep the database values compact so we can avoid traversing large\nBLOBS.\n\nHowever, they came at the cost of code-complexity, and we lost all the\nbenefits of our storage layer, such as transactions.\n\nMeasurements showed, that for email (the intended primary usecase),\nthe overhead is hardly measurable, with most parts performing\nbetter, or at least not worse. We additionally also gain file-system\nindependence, which may help on other platforms.\n\nThe biggest drawback is probably that large payloads need to be written\nto disk twice, because of the synchronizer queue (once for the queue,\nonce for the actual data).","distinct":true,"url":"https://api.github.com/repos/KDE/sink/commits/9b84aff4b68c3cef3328c85ac12418048b169cee"},{"sha":"95854555f038708ddb3fe2e7244deaa57e9a4b8c","author":{"name":"Christian Mollekopf","email":"b722e7edb0e857c64003942e3906e2a94832df33@fastmail.fm"},"message":"Removed all traces of BLOB properties","distinct":true,"url":"https://api.github.com/repos/KDE/sink/commits/95854555f038708ddb3fe2e7244deaa57e9a4b8c"}]}
{"actor":{"display_login":"kdesysadmin"}}