This has gotten some more attention:

The reason was that we had a concurrent read-only transaction so we ended up accumulating a lot of free pages. Fixed in 0dc8aa249d063a3d6eaa248950c57ed5a1709524

The above commit wasn't it (reverted it locally), but still can't reproduce atm.

Can't reproduce, might have been fixed by the recent 1b416946f7c06ff075c7a7d2abacf05705500c3f

The etag cache is no more.

That's probably because you need kdav2 0.3. And cmake in sink should actually complain if that's not available.
Feel free to reopen if that was not it, but I'm sure the branch builds with the right dependencies.

For the time being we're using the approach that sets dtend to the recurrence end (calculated for 10 years).
This seems to work well enough for the time being.

An alternative approach would be to redefine dtstart as the end date of the overall recurrence.

Fix the usage of supportsPrincipals when I really wanted supportsCTags

I think I've found it. From the Google Contacts API, we find that the Home Set (/lists) contains all the other address books (/lists/default being one of them, but there can be more), but no contacts, so from my understanding, this is why the Home Set does not have any CTag. For some reason, it is also not possible to get the CTag of child collections from the /lists URL. I think the best solution is to refresh every collections individually in KDAV2 in the DavCollectionsFetchJob.

No, we do have the Content-Type: text/xml; charset=utf-8 in KDav2 (Google apparently don't care if it's text/xml or application/xml, and from the XML RFC, the only difference between the two is human readability). The issue was more in the way I was testing from the command-line. The issue with Sink seems to be that Google can't find the getctag property (whereas it works from the command-line). This is weird since the propfind.xml is basically a copy paste from Sink's logs.

looks like this is what the client is supposed to do anyways (http://sabre.io/dav/building-a-carddav-client/), so let's make sure that we have something like Content-Type: application/xml; charset=utf-8 in the request.
Is this perhaps something that we generally have missing in all requests in kdav2?

Well, it seems that Google is completely ignoring the request if the Content-Type: application/xml is not present so adding -H "Content-Type: application/xml" to Curl's command line does the trick, and Google returns a valid CTag

• Fix model notifications by fixing the contains function
• Add tests to the contains and exists functions from the Entity store

Fix the testModifyWithConflict from pipelinetest by fixing the readRevisions function which was still using UIDs to access a main database. Now it uses the uidsToRevisions database.

• Fixed the random reading issues on database with integer keys with great help from Christian
• Fixed the readPrevious function from the entity store
• Fixed dumb issue in the size_t variant of the scan function
• Add some storage tests

It didn't take multiple collections into account.

Binary UID is in, revision separation is WIP.

Resolved by not limiting the search results as early as we used to.

Sorry for the late reply, I have missed this ticket.

This wasn't even the right backtrace.

Excellent, thanks =)

Put syntax and REGISTER_SYNTAX at the bottom

Looks great =)

Better explanation of the --reduce option in the list command

Wrap assignment in lambda

Make assignation clear.

In D14099#296060, @rnicole wrote:

The benchmark tables are now updated, for some reason, memory went up in "Run benchmarks", but down in "Test Disk Usage"

The benchmark tables are now updated, for some reason, memory went up in "Run benchmarks", but down in "Test Disk Usage"

• Since Keys and Identifiers can now be "null", we can convert the selection part of the Reduce filter to use Identifiers
• Also added the operator== and operator!= to Identifier, Revision and Key
• Benchmark update coming up