That probably won't have to happen anymore.
svn monorepository needs to be ingested in a specific way.
A new task will get created for this.

In T3870#77439, @swh-sentry-integration wrote:

Sentry issue: SWH-LOADER-SVN-55

Related to T611 (asf repo is a monorepo and it's containing svn:externals properties)
Related to T3839 (we are dealing with large repositories here)

In T3870#77435, @swh-sentry-integration wrote:

Sentry issue: SWH-LOADER-SVN-4Z

In T3870#77434, @swh-sentry-integration wrote:

Sentry issue: SWH-LOADER-SVN-57

In T3870#77482, @swh-sentry-integration wrote:

Sentry issue: SWH-LOADER-SVN-2Y

Sentry issue: SWH-LOADER-SVN-2Y

In T3870#77432, @swh-sentry-integration wrote:

Sentry issue: SWH-LOADER-SVN-53

In T3870#77433, @swh-sentry-integration wrote:

Sentry issue: SWH-LOADER-SVN-4Y

In T3870#77431, @swh-sentry-integration wrote:

Sentry issue: SWH-LOADER-SVN-50

In T3870#77430, @swh-sentry-integration wrote:

Sentry issue: SWH-LOADER-SVN-58

Sentry issue: SWH-LOADER-SVN-55

Sentry issue: SWH-LOADER-SVN-4Z

Sentry issue: SWH-LOADER-SVN-57

Sentry issue: SWH-LOADER-SVN-4Y

Sentry issue: SWH-LOADER-SVN-53

Sentry issue: SWH-LOADER-SVN-50

Sentry issue: SWH-LOADER-SVN-58

@ardumont deployed swh-loader-svn v1.0.0 on staging and restarted the loader service.

Sentry issue: SWH-LOADER-SVN-1Q

This PDF contains my SVN Loader review report.

My recent work on fixing the subversion loader issues in production based on sentry reports made me think again about how we could resolve that task.

Diff deployed through the v0.10.1

If i'm not mistaken, there has been some more work about this.
This got deployed with the v0.10 package btw.

Deployed ^ as part of the v0.9 package.
Let's see if that defiintely fixes that wrong pattern.

Since D6608 got landed and deployed to production, revision reconstruction discrepancy is detected earlier and there is already a couple reported on sentry,
so keeping this opened.

so:

/tmp/tmp0tm0182g/swh.loader.svn.2zdkkl_5-1740204/tmpi0q7t29s: mounted svn repository (from a dump)
/tmp/swh.loader.svn.mhx2lwbz-1740204/tmpi0q7t29s: svn loader's repository disk copy growing along the ingestion

I've triggered runs on those origins with the patched loader btw.

Diffs landed, packaged and deployed.
Closing.

@posenato Hello, i was gonna check this morning and ping you to let you know.

It has just finished saving the repository.
It worked perfectly.
Thank you a lot for your support.

All fixes have currently landed, got packaged in v0.7.3.
I've deployed it and triggered a run [1] for the origin (ongoing).

The issue is related to the difference of fetched revision data whether we use the swh.loader.svn.SvnLoader class (fetching revisions
one at a time through a ping pong with the svn server) or the swh.loader.svn.SvnLoaderFromRemoteDump class (fetching all revisions
to a dump file in one operation).

Original comment posted in T3695 by @ardumont

The loading issue for the repository in T3694 description has been identified: a commit message has been modified
server side between two save code now requests leading to a discrepancy in computed hashes for revisions.

@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!

@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.

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.

Ah, it's not for all origins though...
I tried with other origins which demonstrates the same issue [1] and they did not fail...

For this one, i had a thought about it recently and it should be enough to trigger a
run from scratch (loader has the flag for it which is tested but got never used).