(thanks)

as discussed, this diff should be abandoned

I've addressed this as in rDSTO16ffb6eb9264a367a595c83c19babcfe7fb8e432
Unless you disagree with that solution, please abandon this diff

I've addressed this as in rDMOD6f5d74b261a3571b1915710d729af5d6ceb8804e
If it's OK with you, please abandon this diff

As far as I can tell from their documentation this cannot be made to work, because they only support http://identifiers.org/[collection]/[entity] as meta-syntax, and even use query strings for their profile stuff.

requesting changes discussed in D453#8780

requesting changes discussed in D453#8780

updating diff status to match the current state of the discussion

In T1225#22798, @anlambert wrote:

$ curl -L https://npmjs.org/install.sh | sudo sh

This is now done.

cc: @douardda , just because we discussed this today :)

thanks!

Thanks, this was indeed a problem and this solution works.

In T611#22696, @ardumont wrote:

@zack Can you enlighten me as to why we want to store that information at the directory level (and not say at the revision one)?

So, the problem is that running "make" into swh-model/docs/ should also run "make" into swh-model/docs/images/, which currently isn't done. (And, symmetrically, make clean should also clean under images.)

In D451#8735, @vlorentz wrote:

~/swh-environment/swh-docs/docs
make

can you tell me how did you build?

There is no CI building the doc for now (which is a problem per se, but that's a different debate :-)) However I did publish the doc myself ~1 hour ago.
I think what happened is that the last person who published the doc (I think @seirl ) didn't build the images locally and published that way, inducing the error you were seeing.
This is certainly proof that our publishing process for the doc is too flaky.
But on the other hand I don't think this diff is needed — the problem is elsewhere, e.g., doc build should fail rather than publish broken docs.

Images like the one you mention are working on docs.s.o, see https://docs.softwareheritage.org/devel/swh-model/data-model.html#data-structure .
So I need some more context to understand this diff. Can you elaborate?

In D446#8588, @ardumont wrote:

You might already be working on that, but that's worth mentioning, there remains to:

• check the indexes file (sql/swh-indexes.sql) to drop the releated indexes

• SQL: drop obsolete indexes and functions related to occurrence tables

\o/

Thanks, I liked the idea. I've only reported minor things here and there.

Thanks, this is indeed much simpler.

I'm not sure why the status of this diff is abandoned, but I'm picking up the discussion on whether the mercurial loader should create release objects because it started here.
Since we last exchanged here, we also exchanged f2f, so rather than picking up all the sub-thread I'm focusing on the main points.

definitely a bug, thanks for reporting!

for comparison:

• https://github.com/robots.txt
• https://gitlab.com/robots.txt
• https://bitbucket.org/robots.txt

being crawled along million-revision VCS histories doesn't sound particularly appealing :-)

in terms of UX, I think this should do something like:

• show the default branch (HEAD) if no explicit branch has been requested, some branches (according to whatever pagination is implemented by the back-end) and tell the user "sorry, this snapshot has too many branches to be shown…". GitHub does something similar for very large dirs, and it's totally fine. (BTW, do we have something similar for very large dirs? we should!)
• if an explicit branch has been requested, show that one instead of the default one, and do as above for everything else

FWIW, this is my main worry about this approach.

+1