Jan 8 2023
Jul 3 2019
Apr 15 2019
I think we can close this one :-)
Feb 20 2019
Sep 3 2018
A possible problem to check with this workflow:
hal-prod and hal-preprod uses the same identifiers for different objects
Aug 29 2018
After the session with Bruno this week, we saw that multiple request of the same deposit that are waiting for the workers create a corner case where each is treated as a different deposit and each is loaded into the archive separately. For example this deposit -https://archive.softwareheritage.org/browse/origin/https://hal.archives-ouvertes.fr/hal-01862659/visits/ with 9 visits but not related through the parent history.
Jul 24 2018
Jul 23 2018
Jul 20 2018
Jul 19 2018
We want to return in the SWORD response all the information (including context), but structured, so the receiver does not need to do parsing:
Just to be clear about this:
- the property swh-id returned to the client is the directory, with or without context?
- swh:1:dir:42a13fc721c8716ff695d0d62fc851d641f3a12b
- swh:1:dir:42a13fc721c8716ff695d0d62fc851d641f3a12b;origin=https://hal.archives-ouvertes.fr/hal-01727745
- How should we call the new property added for the revision ID ?
- And will it be a revision ID with or without context?
Similarly to what we do for the loaders (e.g., with the Git pack files), we should just keep everything (metadata + tarball) received from a deposit in raw format somewhere, to allow further re-processing. So I think this issue should not only be about keeping raw metadata, but rather the entire (raw) deposit.
Good idea!
Like i said orally, this task makes me edgy:
Jul 18 2018
I'm adding this meta-task to the grand HAL-opening thinking it can (and should) be resolved after accomplishing this milestone.