In SWHIDv2, instead of having a hardcoded "pointer to another revision" directory entry type, we could enable pointers to more generic "unresolved external entities". When possible, we should make these pointers compatible with the current ExtID table, so that users of the data can look the contents of the pointed objects up lazily.

Ideally this doc would (briefly) describe how bazaar works and how it is different from already supported DVCS, then document chosen the "mapping" of the bzr model into swh (especially mentioning what is lost during this).

Would it be possible to add a "conception documentation" included in the docs/ of the BZR loader repo? (possibly with D6344 or as a standalone diff)?

The conclusions in the meeting were as follows:

Complete proposal for the above solution:

Complete proposal to implement the above solution:

Possible solution: store them as an ascii string instead of an integer.

Possible solution: store a rank along with each directory entry, but ignore it unless we are reconstructing a git object or computing a SWHID (v1?)

I just gave this a shot, and I can't find a way to encode large timestamps in postgresql without losing microsecond precision.

If we also implement it as a fallback on the backend side, we should find a way to determine if an input save code now request has been created from the Web UI or through a direct call to the Web API.

This should happen both client and server side (as fallback).

closed by https://forge.softwareheritage.org/D5825

A recent discussion occurred on the #swh-devel irc channel about this issue. The gist of
it is that regarding github repositories (in the save code now [1]), the webapp should
be evolved to query the github api to determine the canonical url used for a repository
and use it as origin.

Closing this as it was a vague meta-task from 2020 roadmap (but we'll keep the actual sub-tasks, which were more clearly identified and are still relevant).

In T3298#64431, @anlambert wrote:

So for SWHID v1, the resolver should turn the core part into lowercase , am I right ?

I'm not a fan of changing the spec of SWHID version 1 to make them case insensitive, as it seems to be a significant change (in particular for the code that checks for the syntactic correctness of IDs).

Examples of such missing objects are revisions with attributes that cannot fit the current data model, e.g. out of range dates. We have example of such revisions in kafka, as mentionned in T3200 and T3170.

Note that none of their parent revisions can be found either in the archive (one invalid revision in a set of ingested revisions prevent any of them being inserted in the database I suppose, but they are already inserted in kafka at this moment).

In T3235#63002, @libEqualizer wrote:

You are likely doing a git pull on a periodic basis. Just add git bug bridge pull [<name>] next to it.

However, this would require considerable work

Hi, thanks for the suggestion.

In T3226#62710, @vlorentz wrote:

You should install swh.model[cli] instead of swh.model. I added a better error message in D5466 so it's clearer.

And I'm also updating the documentation at https://docs.softwareheritage.org/devel/swh-model/persistent-identifiers.html#computing

You should install swh.model[cli] instead of swh.model. I added a better error message in D5466 so it's clearer.

Resolved by D5460; thanks again for the report

looks like there is no revision with date or committer_date > 9999-12-31 in the main storage...

duplicate with T3160

Already implemented in D4193

(and we should keep the origin topic; we already have an ExtSWHID for origins anyway)

The following objects remain: