Duplicate of T3724 I think

At least loader deposit and npm [1] are fine.

Here is an overview of the fields (+ internal version name + branch name) used by each package loader, after D6616:

I came across a rather small repository [1] which i believe raise the same issue.
So it may help to keep its reference to ease the testing of the improvment discussed here.
Feel free to dismiss if not that useful.

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).