When I tried to generate cook some vault in productions, several error where logged.
Some on missing commit, for example:

missing commit 338fb3eff7e93e121e7fe347b391a100ed0003c5
missing commit 73bc01d26ae7d61a74108b620e32458ef30c75c6
missing commit 78272793666b7354f6be373a73aa62426116d884
missing commit 83f434d5f256886fcfcfc354c3a63b91a71fce63

All these hash are identified in the work on T75 so they are not blockers

Nice, thanks!

@ardumont I revisited all comments and noticed I missed a few, sorry about that. They should be good now :-) Is there anything else you need me to do for this proposed patch? Or should I just be patient and wait for whatever comes next in the review merge process? Thanks for your guidance!

Build is green

add two missing type annotations

Nope, if loaded with only one direction, traversals will only be possible in the loaded direction.
This will essentially be a trade-off setting for people who cannot (or doesn't want to) load both direction.
It is fine to fail (gracefully, with an error) traversals requested in a direction that corresponds to a non-loaded graph.

Should this still allow the possibility of browsing both directions?

Thanks for the summaries @olasd, both here and on list.
I've followed up on list.

@anlambert, thank you for excellent analysis!
Yes, I made an adjustment of commit logs because there was an error during the release and I discover it very soon, so I preferred to make the release again adjusting the comments instead of to make a new release!

Got fixed with a741222342b5b74cd4ee9db1da8e99c280602524

a741222342b5b74cd4ee9db1da8e99c280602524

Looks good to me, thanks !

In D6395#171086, @ardumont wrote:

[1] scheduler: D6520
[2] docker container: D6543 (to deploy ^ in the docker world)

So those landed. So now you should rebuild the containers [1] to have the most recent
scheduler version (after the listing is done, the scheduling of the maven origins should
happen).

First, make sure to reference in the the loader configuration [2] the new maven task
[3], override your service containers (lister and loader) with the right override and
you should be good to go [4].

Now that we've made some progress (and changes) on the lister I'll re-try that, with the proper loader conf. Thanks for the hint.
I'll keep you posted (probably next week though).

Build is green

Missing tests

@posenato, I did some deeper analysis on why your svn repository could not be loaded anymore into the archive
and it turned out @ardumont is right, the commit log of your repository got altered between two save code now requests.

Build is green

• maven-lister: Split parsing and processing

used another approach, see D6571

Build is green

apply vlorentz' comments/suggestions

Build is green

fix test_cli

Build has FAILED

Build has FAILED

rebase and a few fixes

Build is green

review changes

Looks good to me ! I added a couple of nitpick comments to handle before landing this.

In D6578#171009, @aeviso wrote:

Do you mean something like this?

Build is green

Build has FAILED

Hi,
if you need to have an SVN log from the SVN server, I can ask our sysadmins to have an extract of the log.

"fix" mypy

Minor correction in doc string

In D6570#171059, @douardda wrote:

In D6570#170758, @vlorentz wrote:

You checked on the whole journal, right?

not yet. The shouldn't be any left, but... I'll check as soon as I have credentials for the production kafka cluster.

Build has FAILED

In D6395#171086, @ardumont wrote:

[1] scheduler: D6520
[2] docker container: D6543 (to deploy ^ in the docker world)

So those landed. So now you should rebuild the containers [1] to have the most recent
scheduler version (after the listing is done, the scheduling of the maven origins should
happen).

Thanks for the hint. I'll first refactor the parsing loop and then run the whole process as suggested.
Will keep you posted asap.

Build has FAILED

Build has FAILED

Build has FAILED

Bump the dependency on swh-journal to 0.9

[1] scheduler: D6520
[2] docker container: D6543 (to deploy ^ in the docker world)