looks good, thanks! only minor changes requested

In D424#8216, @ardumont wrote:

I guess that concludes the discussion in D409 then (mercurial tags representation in swh model ~> snapshot with an equivalent naming convention).

here's a random list of contributed icinga checks to monitor the state of a systemd service:

• https://github.com/melmorabity/nagios-plugin-systemd-service
• https://github.com/hkbakke/check-systemd-service
• https://github.com/pengutronix/monitoring-check-systemd-service

not tested and i'm not entirely sure to have looked in all the right places…

In T1179#22308, @olasd wrote:

The name server itself works but I had not pointed the azure hosts to this mirror yet.

We should also add monitoring to make sure the zones stay in sync.

Thanks for your analysis.

https://forge.softwareheritage.org/tag/unreproducible/

In T1198#22278, @anlambert wrote:

Honestly, it would be too much of a hurdle. Using node/npm is quite common in web development today
and users who want to hack on the webapp locally should not be suprised about having to issue a 'npm install'
command before being able to run it (this is also explained in the README).

According to this log, we need at least 10.x:

now that T1193 is out of the door, i'm adding it a note about the need of updating the getting started doc when this is done

db-init has been updated a while ago to force UTF8 encoding, and it is now the documented way to initialize the DB, so there is no need to further specify DB encoding requirements elsewhere

In T1194#22202, @olasd wrote:

However I'd be happy for the static default landing pages to tell people that, and to point to the (static) API documentation of the respective components.

So, as discussed today f2f, I don't like getting rid of release objects. For at least a couple of reasons.

The idea of using a chain of responsibility where loaders can check specific URL is indeed nice and elegant.

In T570#22071, @anlambert wrote:

Based on my understanding, this property does not seem to be taken into account
when using the remote access replay api and thus the reconstructed files may
contain different line endings as those generated by 'svn export', so there is a
tree divergence.

Nice catch.

less is more, I like "Save code now" best :-)

rDSTO329d0f920895f22aa6c34cd317b8ce1674e869af is in fact a work-around for this

looks good to me, just two minor nits for your consideration:

(pinging this issue, because it's 2018, and it really looks bad that we're apparently not capable of quickly returning results in our main search :-))

[ updated the message above in-place to add 3 and 4 ]

We want to test the end-to-end functionalities of the vault. Various use cases should hence be tested:

Thanks @anlambert , SPAM originating from the contact form dropped to zero after this change!

In T421#21693, @olasd wrote:

• Unpack all the sdist formats
• If things are well, the contents are identical. In that case, the revision objects would end up with the same id; we can ignore that there ever was multiple formats, and just have a single branch pointing to a single revision for that version of the package in the snapshot
• If the contents are different, load both and make the snapshot have a branch pointing to each format.