lgtm *but*:

• you should remove the ".84" part in the timestamps (I first read 1h -> 42h)
• I'd like the commit message to give a bit more details on what this diff really is doing (if I get the idea, keep the directory structure between 2 revisions and "apply the modifications" rather than rebuild the whole structure, right?)

typos and (somes) fixes reported by vlorentz

In D4633#115780, @vlorentz wrote:

Oh, and you need to add something to explain anonymized topics

typo

Note: I have not made any proofreading yet, so it should be full of typos and errors...

LGTM. I was wondering if a regexp would not be simpler for the validation step, but it would make error message more generic and less user friendly.

ok we are getting close I think. Just a few more comments to be handled and we are done.

I think the best would be to put this directly in swh-docs ( rDDOC ) because it's kind of "transverse" between swh-journal, swh-storage and swh-indexer.

Thanks!
it's not completely clear why the @never_cache did not work any more, but meh.

This may be better suited to a fix in the web API, via proper cache config headers, as @olasd mentioned on IRC (probably via https://docs.djangoproject.com/en/3.1/topics/cache/#downstream-caches )

bit sad indeed, but LGTM

lgtm (besides the retries_left=3 stuff)

ok ok ok

In D4554#113843, @douardda wrote:

swh.core[db] is already a dep in requirements-swh.txt, why would is be needed here?

But more importantly, I disagree with the validity of the diff because pytest-posgtgresql is used directly in this package (in conftest.py), not only by the mean of the swh.core.tests.db package.

swh.core[db] is already a dep in requirements-swh.txt, why would is be needed here?

In D4463#113349, @vlorentz wrote:

I disagree. We don't want to re-use it, but to create a new tag entirely.

Besides @marmoute 's comments, lgtm

if we are confident this really is the correct URI, lgtm

(maybe with a better ci msg)

I would put (at least part of) the diff's message in the commit message, otherwise lgtm

it looks good to me, but, yeah...

lgtm (besides the red CI flag)

Note that we will need to keep the support for SWORD v2 (at least for a while), so this open question must be tackled with this in mind.

In T2537#52900, @ardumont wrote:

Is this related to T1021?

I'd say yes, i added that task as parent task.

why store the current tab in a variable instead of just asking it when needed (using something similar to e.currentTarget.text.trim())?

In D4490#112041, @vlorentz wrote:

IMO the SWHID class should store the parsed core SWHIDs for its qualifiers, so they don't need to be parsed twice (+ error handling)

Is this related to T1021?

It seems to make perfectly sense to use the same logic as the metadata deposit to handle this problem, I think.

In T2779#52735, @douardda wrote:

I may have missed something (several actually) but where is this swh:deposit namespace specified?

We need to think about a better UI for this, but I have no solution for now.

To solve this discrepancy, deposit message should be added in the xml.

I may have missed something (several actually) but where is this swh:deposit namespace specified?

Also I believe this will have its priority to be elevated once the staging is officially made public

I vote for the big fat red banner

I don't understand this. I guess https://www.softwareheritage.org/check-deposit-2020-11-15T21:58:29.744061 is the Origin URL of this deposit https://archive.softwareheritage.org/browse/origin/directory/?origin_url=https://www.softwareheritage.org/check-deposit-2020-11-15T21:58:29.744061 right?

In D4463#111659, @vlorentz wrote:

What bugs me is that said url does not make sense (when that slug is generated), that url means nothing...

It does mean something, it's an URI (resource identifier) but not an URL (resource locator)

I don't mind a "quick" solution that fixes the problem right now, and revisit it once we have T2459 fixed. Not sure I agree with the statement that my proposal in the comment is "fine-grained" though. I mean I suggest nothing fancy, just a few entries in a dropbox which content is built from the "directories" of the branch names.

maybe a generic widget allowing to select the "directory" to show in the branches view, For example, in this DGtal repository, it would propose a dropbox with the following items:

In D4463#111625, @ardumont wrote:

if the slug is not sent, then the id is generated (like we currently do in the cli) but server side.

Let me clarify, that's a hack that was installed for a specific user (which does not use it in the end).

I don't want that hack from the cli ending up server side...

We should probably rework the origin logic first then.

In D4463#111573, @ardumont wrote:

Something is amiss for me somewhere.

I thought we wanted to relax the slug's mandatory property (to respect the sword v2 spec).
If that's the case, we still need the external_identifier in the loop.

Because that's what's used at some point to build the origin for the loader.

What did i miss?

Because, from my understanding of another discussion with @douardda
or @moranegg, i thought it was the other way around.
Keep the external_identifier and use it if not provided by the slug.

So that way, we can go the optional slug road.

rebase

keep the cli options but mark them as deprecated (and ignored)

rebase

In D4432#110488, @ardumont wrote:

As i mentioned in irc during the week, I'm pretty sure those are to be used alongside
the --replace flag. So not sure if it's wise or not to remove those...

But i guess your argument about deduction out of --archive and --metadata flags stands.

Also, kinda in the same vein as vlorentz's comment, i just don't know who is using those
nor how to actually check that.

Maybe deprecating those flags, then actually explains that they
are redundant with --archive and --metadata would be best as a first step?

As said on IRC, I think I'd rather prefer erroneous hashed to be logged somewhere rather than using an assertion.

overall I'm ok, but I find it really lacks some documentation/explanations of how this works, especially the JournalWriter collaborator object

rebase

rebase

rebase

rebase

rebase