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.

This task has been migrated to GitLab.

The actual issues were currently not reported properly. It's now fixed.

Currently deployed in staging and production.
So future listing will do the right thing.

Could you please also open a diff with the necessary changes required for the docker
stack (swh-environment/docker changes you had to make to actually have the loader run
properly)?

@stsp as mentioned in the main task, it'd be neat if you could create yourself an account in sentry [1].
Ping me when it's done so i can invite you in the #swh-team so you can browse the cvs loader
related issues from there.

This has been done though the debian improvment tooling task [1].
Jenkins builds and uploads debian package as usual after a git tag on the repository.

I found one additional problem. See D6823.

Unless I have overlooked something, all currently known issues have now been addressed.

Unless I have overlooked something, all currently known issues have now been addressed.

I have started test conversions of the OpenBSD CVS repository.

D6684 addresses another keyword expansion issue found while testing conversion of CVS's own history.

The above problem with the Header keyword can be worked around (at least for the GNU savannah site) with the patch in D6678.

Another problem with keyword expansion found during testing:

In T3691#73518, @stsp wrote:

There is another problem related to keywords: Some CVS-based projects use custom keywords, instead of the standard $Id$ keyword. This prevents wrong expansion of $Id$ when code is imported from one project to another. Usually the project's name will be used as the custom keyword name, such as $OpenBSD$ or $NetBSD$, instead of $Id$. At present, to expand keywords correctly in this case, we need to use the pserver access method to benefit from server-side keyword expansion. But we will end up with different hashes if rsync is used to import the same origin again. We might be able to auto-detect use of custom keywords if the rsync server allows access to the CVSROOT folder, but this is not always the case. If CVSROOT is hidden from rsync, the only reliable way to detect custom keywords would be a parameter that gets passed into the loader. We could, for example, allow passing the name of a custom keyword as a parameter embedded in the origin URL.

As of D6623 the CVS loader is able to convert GNU dino correctly over both rsync and pserver access.

Status update: