This task has been migrated to GitLab.

This task has been migrated to GitLab.

This task has been migrated to GitLab.

This task has been migrated to GitLab.

This task has been migrated to GitLab.

Fixed and deployed.

This is a regression induced by commit rDLDSVN04566a7f3616fb94063355aae491a4e5ad4a832f, I understood the issue and I am working on a fix.

Oh awesome! Thanks for pushing forward. :-)

Oh awesome! Thanks for pushing forward. :-)

fwiw, I've iterated a bit over @zimoun's code and pushed it into the snippets repository
(see commits above and their commit description message). It's also able to deal with
git, hg and svn trees (ignoring their respective top metadata folder .git, .svn, ...
without impacting the performance).

This task has been migrated to GitLab.

This task has been migrated to GitLab.

This task has been migrated to GitLab.

This task has been migrated to GitLab.

This tree

$ tree foo
foo
├── bar
│   └── exe
└── baz

To be complete, the integrity checksum that Guix provides (here one example about the package guix-modules),

Related to P1473.

Thanks for raising the questions.

yes, nix too. As far as i remember, it's NAR for Nix ARchive ;)

Indeed, it looks like @ardumont already did this in D6630. Sorry

Hi, @vlorentz I have checked swh/loader/svn/svn.py, and it is annotated, can you guide me where are the annotations required.

Hi @vlorentz I would like to work on this task too.

Fixed and deployed.

Fixed and deployed.

In T3870#78042, @vlorentz wrote:

seems to still happen on 1.1.1 https://sentry.softwareheritage.org/share/issue/d6330b7c048249d99342e4c9d56dce19/

seems to still happen on 1.1.1 https://sentry.softwareheritage.org/share/issue/d6330b7c048249d99342e4c9d56dce19/

Below are the results of the loading of the subversion origins listed above, I used a filtered version of the webapp database on staging.

13:36 $ sqlite3 swh/web/settings/db.sqlite3 
SQLite version 3.34.1 2021-01-20 14:10:07
Enter ".help" for usage hints.
sqlite> select visit_status, count(*) from save_origin_request group by visit_status;
failed|18
full|76
partial|83

So 76 origins that could not be fully loaded with swh-loader-svn v1.0.0 are now correctly processed with v1.1.0.

python3-swh.loader.svn v1.1.1 deployed on staging, production ongoing.

Sentry issue: SWH-LOADER-SVN-54

swh-loader-svn v1.1.0 has been released, new tests have been scheduled on staging (T3875#77706).

Subversion origins that failed to load or with a partial visit status when using swh-loader-svn v1.0.0 (T3870#77580)
have been resubmitted on staging to check how many can now be fully loaded using swh-loader-svn v1.1.0.

staging:

• Package python3-swh.loader.svn upgraded
• Service swh-worker@loader_{svn,high_priority} restarted

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

Sentry issue: SWH-LOADER-SVN-4Z

All loading tasks submitted on staging last week got executed. Below are the results after updating the staging webapp database in my local environment:

(swh) ✔ ~/swh/swh-environment/swh-web [master|⚑ 106] 
11:10 $ sqlite3 swh/web/settings/db.sqlite3 
SQLite version 3.34.1 2021-01-20 14:10:07
Enter ".help" for usage hints.
sqlite> select visit_status, count(*) from save_origin_request group by visit_status;
failed|26
full|711
not_found|3
partial|153

Once T3870 fixes land, we'll release a new version of the loader.
See T3875.