Is anyone still using the JCL's UnitVersioning functionality?
Is anyone still using the JCL's UnitVersioning functionality?
Every JCL and JVCL unit registers itself to the JclUnitVersioning across module boundaries. The registered data contains the SVN revision and last commit date which can be used to show the data for every unit in an exception dialog.
Well, it is broken and not only because all the SVN data (revision, date) is missing since the projects moved to GitHub. If you use DLLs that contain JCL/JVCL units and are loaded dynamically and not unloaded before the EXE's JclUnitVersioning finalization ran, you will get access violations.
The code is only partly thread-safe what means it is not thread-safe. So loading such a DLL from a thread can cause a race condition.
I had a look at the code and I don't see an easy way to get the current implementation to work without rewriting it. But why rewrite it if you can delete it. All the data is missing anyhow. So I see no point in fixing code that nobody would even find useful anymore.
Every JCL and JVCL unit registers itself to the JclUnitVersioning across module boundaries. The registered data contains the SVN revision and last commit date which can be used to show the data for every unit in an exception dialog.
Well, it is broken and not only because all the SVN data (revision, date) is missing since the projects moved to GitHub. If you use DLLs that contain JCL/JVCL units and are loaded dynamically and not unloaded before the EXE's JclUnitVersioning finalization ran, you will get access violations.
The code is only partly thread-safe what means it is not thread-safe. So loading such a DLL from a thread can cause a race condition.
I had a look at the code and I don't see an easy way to get the current implementation to work without rewriting it. But why rewrite it if you can delete it. All the data is missing anyhow. So I see no point in fixing code that nobody would even find useful anymore.
Comments
Post a Comment