rebase on master and apply vlorentz' suggestion

In D5811#147864, @douardda wrote:

@aeviso I have a question: in this scenario, do we expect the date in the directory table for A/C and A/B/C (sha1 c9cabe7f49012e3fdef6ac6b929efb5654f583cf) directories to be invalidated or updated due to the arrival, at rev R05, of a version of the b file dated earlier than originally seen in R01?

rebase

rebase

rebase

rebase

rebase

rebase

rebase

rebase

rebase

rebase

rebase

actually pick the correct revisions for this diff...

rebase

rebase

rebase

fix typos, add more comments/docstrings, and remove completly the IsochroneNode.files attribute

In D5781#147873, @aeviso wrote:

This diff is already accepted by ardumont, who knows SQL better than I do. There is no much for me to review here

In D5781#147873, @aeviso wrote:

This diff is already accepted by ardumont, who knows SQL better than I do. There is no much for me to review here

In D5813#147855, @aeviso wrote:

Why would we want to do this? The actual idea is to guarantee that the commit method never fails, so we can remove the while not provenance.commit() line in the revision_add function.

In D5781#147856, @aeviso wrote:

We are about to start refactoring the provenance backend. It would be nice to have this changes pushed, since re-basing them might by complicated after refactoring.

@aeviso I have a question: in this scenario, do we expect the date in the directory table for A/C and A/B/C (sha1 c9cabe7f49012e3fdef6ac6b929efb5654f583cf) directories to be invalidated or updated due to the arrival, at rev R05, of a version of the b file dated earlier than originally seen in R01?

In D5773#147275, @douardda wrote:

In D5773#147221, @aeviso wrote:

I'm not really sure this new algorithm does the same as the previous one. Some subtle things were changed and I have the filling the semantics are different now. Also, I found the previous version to be clearer, I rather stay with it

rebase

rebase + use set() to compare expected results, as requested by aeviso

rebase

rebase

In D5780#147451, @vlorentz wrote:

what about disabling E501 for the whole file, instead of repeating the comment? https://stackoverflow.com/a/64431741

rebase

In D5772#147476, @aeviso wrote:

Not sure if I follow what the test is doing since it not clear to me what's the content of storage_and_CMDBTS,

In D5773#147221, @aeviso wrote:

I'm not really sure this new algorithm does the same as the previous one. Some subtle things were changed and I have the filling the semantics are different now. Also, I found the previous version to be clearer, I rather stay with it

rebase

rebase

rebase

rebase + also apply to add_child()

rebase

small improvement of a comment + type annotation for the local variable 'fdates'

consider the minor fix in the README file, otherwise ok, thanks!

please also add a piece of documentation somewhere on this alt. "cassandra" backend config (aka. "how to use scylladb" or something).

tests are green, so it should be ok I guess

LGTM, any reason for not landing it?

rebase

rebase

Make the number of (single-object insertion) retries configurable