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

rebase

remove remaining mentions of the "simplified metadata deposit"

typos and some fixes according to comments

In T2767#52345, @moranegg wrote:

I need to reflect on this.
There were two major reasons for which we use the slug:

1. create an origin

I've merged T2757 in this since there indeed identical

adapt according to vlorentz' comment

typo (thx vlorentz)

Rebase, updates and fix according to moranegg's comments

I also think that if we use the "blueprint" terminology, then the blueprint section should list all the specifications, implemented or not, but make it very clear what's done, in-progress or only planned.

• I wonder if it would not make more sense to put spec-meta-deposit.rst and spec-sparse-deposit.rst within blueprint.rst since these are other "use cases"
• I don't really get the point of the specs/spec-technical.rst file - it should be deleted (maybe keep one or 2 paragraphs in there)
• I think dev-info.rst and sys-info.rst should be moved in a subsection ("Reference" or "Technical Doc" or something)
• I think the tests/tests_HAL.rst file should not be in the docs

fix formatting in the docstring of client_command_parse_input()

Agree with @vlorentz, we should not clean a given SWHID, it's either valid or not

rebase

rebase

fix a few more oopsies reported by vlorentz and ardumont

Fixes according to vlorentz' comments

rebase

rebas

rebase

rebase

rebase