[vtk-developers] Adding VTKData and VTKLargeData as optional submodules

[Marcus D. Hanwell]

Hi,

Berk and I were talking about the situation with VTKData and
VTKLargeData when submitting topics for review. We know about the
content based hashing used in ITK, but were thinking about adding
VTKData as an optional git submodule to the VTK repository in the
interim before we can invest the time required for a migration to what
ITK uses.

Advantages we see in this approach:
 * Can be done in minutes
 * Dashboards will continue to pass as expected when their data SHA is old
 * These submodules would be entirely optional (as VTKData/VTKLargeData are)
 ** Normal development would not require new steps
 * Would allow for topics to definitely push data forward with new baselines
 ** No asking people to make sure they do it once merged
 * Git is now very good at resolving submodule conflicts - simple
linear flow in VTKData

Disadvantages:
 * Still some situations where the baselines could get mixed up
 * Some increased complication when pushing the submodule forward for
new baselines
 * Possible mixups in pushing submodule backwards, easy to spot in
review/CDash at Home

I think overall the process would be less error prone, and would take
the last bit of guess work out of reviewing CDash at Home submissions (is
it red due to being based on older master, with newer master
containing updated test code or because they really broke something in
this topic). I also think that git has matured to a level, and we have
learned as a group where this solution is a reasonable short term
solution. We can also simplify our instructions, and remove the
question of where VTKData etc are located.

Thoughts, objections, alternatives?

Thanks,

Marcus