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.

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.

And also make sure the one visit date is the right one:

• new loader svn packaged and deployed
• origins in error scheduled back
• workers logs (kibana dashboard) [1]

Ok, so going for that fix.

\m/

So here are the results:

I was trying to play with your Python scripts to query kibana logs but it's been a while since I
did not write a query for elastic search and their json format is still awful.

Today is not a good day for me ;)

Great to have kibana back!

Another try with another svn repo gives me the following output:

Great to have kibana back!

I had to configure back the new kibana0 (was banco before) to start parsing those logs back.

This issue is reproduced on 6 repositories (so far, still running locally on some other big repositories).

To my old self, what are those other 5 repositories?

Digging deeper to try and improve the result to return (at the moment, empty string).
I tried to use chardet to detect the language to try and decode the bytes.
This fails as nothing appropriate is found.

By analyzing the repository dump file in emacs

Thinking a bit more about the issue, there might a way to workaround it in our client code instead
of hacking in subvertpy.

Tracking down the issue in subvertpy source code, the error occurs in the subvertpy._ra C extension module.
More precisely, an exception is raised at line 1068 in file subvertpy/editor.c when Python tries to decode a svn property value from 'utf-8' encoding.

1062  static svn_error_t *py_cb_editor_change_prop(void *dir_baton, const char *name, const svn_string_t *value, apr_pool_t *pool)
1063  {
1064          PyObject *self = (PyObject *)dir_baton, *ret;
1065          PyGILState_STATE state = PyGILState_Ensure();
1066
1067          if (value != NULL) {
1068                  ret = PyObject_CallMethod(self, "change_prop", "sz#", name, value->data, value->len);
1069          } else {
1070                  ret = PyObject_CallMethod(self, "change_prop", "sO", name, Py_None);
1071          }
1072          CB_CHECK_PYRETVAL(ret);
1073          Py_DECREF(ret);
1074          PyGILState_Release(state);
1075          return NULL;
1076  }

(If you are not interested in details, no need to look further, it's a run extract ;)

This one is still true. Still banging my head on this.

That's been done for a while now.

I close this as another mirror exists that we already browsed multiple times.

Basic checks on the archive is fine:

This issue is reproduced on 6 repositories (so far, still running locally on some other big repositories).
Those fails are commits holding non-unicode named characters in tree or filename (japanese for example).
What's failing is not clear at all though.

It appears that in this case, the properties must be changed not to the symlink but to its source.

It's more empty repository case than a repository starting its commit range at 0...

This is in stand-by during the snapshot migration.

P202 checked and ok locally.
Now asked for review as it will remove data from the main db.

After discussion with the team, it has been decided to remove from the re-scheduling the svn dumps whose compressed size exceeds 2Gib.
This reflects the same decision took for git repositories.

Scheduled back from saatchi (as i needed the producer credentials to access the queue properties):

Well, there are errors.

• Make sure nothing is amiss