creating a new version fails if the _version_count is not updated correctly

[Jan-Wijbrand Kolman]

VersionedContent.py sets _version_count which (only!) in Versioning.py is used
to determine ids for new versions. However, in certain import-cases (like in the
OCEExtension), the default value for this _version_count may result in incorrect
ids for new versions.

short term solution: hack the OCEExtension to update the value of _version_count
to be correct.

long term solution: Silva should not use this counter to determine an id for a
new version, but rather lookup all existing version ids and deduce a new id from
that information (thx to guido_w for the hint).

[Andy Altepeter (aaltepet)]

_version_count is now referenced in VersionedContent.py, tests/test_version_management.py, silvaxml/xmlimport, adapters/version_management, and Versioning.

Is this something that should be fixed? It seems like a better / more flexible design to check existing version ids and one-up the highest one. I'll be happy to work on this.

[Kit Blake (kitblake)]

Yes, this makes sense.

[Andy Altepeter (aaltepet)]

I'm not sure that converting all object ids within a VersionedContent object to ints, sorting the ints, and then getting the highest number + 1 is the best approach. There may be many versions of the object, so this may be slow. Certainly, it will be slower than inspecting _version_count.

Please advise on whether this approach should be revised.

In the meantime, I've refactored the new version upper in Versioning.py into a get_new_version_id method. This has removed code duplication in Versioning.create_copy and version_management._createUniqueId and test_version_management.create_version.

[Andy Altepeter (aaltepet)]

The primary cause of the issue reported here is during imports. The import system should be handling setting _version_count properly. If it in fact isn't in some cases, we need a modern/current example.

Looking up all existing version ids whenever a new version needs to be created can be rather expensive (thing looking at 100+ versions), so that's prob. not the best approach.