Jan 8 2023
Nov 25 2020
Jul 3 2019
May 25 2019
Sep 30 2018
And also make sure the one visit date is the right one:
Sep 28 2018
- new loader svn packaged and deployed
- origins in error scheduled back
- workers logs (kibana dashboard) [1]
Sep 27 2018
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?
Sep 25 2018
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.
Sep 24 2018
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.
Sep 19 2018
That's been done for a while now.
Jun 19 2018
Feb 14 2018
I close this as another mirror exists that we already browsed multiple times.