and this needs fixing.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jun 7 2021
Jun 4 2021
Also please make sure to add a blank line between the "title" and the remaining of the git commit message (in revision 6c4f25bb8fdb "Refactor [...]")
Store the files and subdirs in dedicated lists in DirectoryEntry
fix typos (thx aeviso) and prevent the creation of a few lists
do not initialize IsochroneNode.maxdate at instanciation time
rebase
rebase
fix a "typo" reported by vlorentz (I missed before)
rebase
rebas
rebase + add a comment in the synth file to explain a bit the "weird" ts in there
allow inline comments in a synth file
I understand that, it's just it can look very weird for someone not really in the project... not sure where to add a comment to make this clear (besides the commit message)
wrong revset...
rebase
rebase
Fix the synth file...
Jun 3 2021
In D5805#148044, @vlorentz wrote:Why did you commit cmdbts2.msgpack instead of regenerating it? Is it too slow?
rebase
rebase
rebase + include a R06 revision
rebase
probably useless now with D5805 coming along.
rebas
rebase on master
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
Jun 2 2021
rebase
rebase
actually pick the correct revisions for this diff...
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
Jun 1 2021
rebase
rebase + use set() to compare expected results, as requested by aeviso
rebase