after F2F discussion: ACK! /o\
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
May 12 2016
May 11 2016
May 9 2016
May 4 2016
Apr 27 2016
Apr 19 2016
Apr 7 2016
Apr 6 2016
We currently have 3'431'504 revisions that need fixing (on a total of 469'428'397, that is 0.73%).
Apr 5 2016
The scripts checking the integrity of revisions and fixing some of them have been committed to swh-storage (in a new utils directory).
Mar 31 2016
Ok, one more reason why we must keep the original data from the dumps.
Mar 30 2016
The dulwich pull request has been merged, and the corresponding package has been added to the local swh archive for importers.
Mar 10 2016
Mar 4 2016
This has been fixed a while ago, for both debian and tarball ingestion.
Feb 29 2016
Done during the big postgres 9.5 upgrade window.
Feb 23 2016
Feb 22 2016
Feb 17 2016
It currently breaks on *completely* empty messages, but the patch seems fairly simple.
Feb 9 2016
Feb 4 2016
Jan 29 2016
Jan 28 2016
This schema change is now done in production.
Jan 27 2016
full SQL code with the new schemata for origin_visit, occurrence_history and occurrence. Those three tables are implicitly relevant only for the "Software Heritage" authority.
Jan 26 2016
Reading the dulwich code a bit further, it turns out that git commits can have more header attributes than we initally expected.
Reading the dulwich code a bit further, it turns out that git commits can have more header attributes than we initally expected.
Dulwich seems to handle some of those special cases just fine.
full SQL code with the new schemata for origin_visit, occurrence_history and occurrence. Those three tables are implicitly relevant only for the "Software Heritage" authority.
Roberto Di Cosmo (via mobile/cell)
Le 26 janv. 2016 07:47, "olasd (Nicolas Dandrimont)" <
forge@softwareheritage.org> a écrit :
This has now been deployed in swh.storage v0.0.30: occurrences and releases can now point to arbitrary objects.
Jan 22 2016
This has now been done.
Still thinking about this .
Jan 21 2016
Currentlly running
I just noticed that empty messages with empty lines are stored as an empty bytea, whereas empty messages without the empty line are stored as NULL. So there's that.
Some example releases:
I have done some investigations on this in light of T272. Bottom line: not good: git is very proficient in the corner cases department.