This task has been migrated to GitLab.

This task has been migrated to GitLab.

This task has been migrated to GitLab.

This task has been migrated to GitLab.

This task has been migrated to GitLab.

I think we can close this one :-)

A possible problem to check with this workflow:

hal-prod and hal-preprod uses the same identifiers for different objects

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.

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:

1. 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
2. How should we call the new property added for the revision ID ?
3. 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:

I'm adding this meta-task to the grand HAL-opening thinking it can (and should) be resolved after accomplishing this milestone.