[vtk-developers] VTK ExternalData default object store

Marcus D. Hanwell marcus.hanwell at kitware.com
Tue May 21 11:46:39 EDT 2013


On Tue, May 21, 2013 at 11:24 AM, Brad King <brad.king at kitware.com> wrote:
> On 05/21/2013 10:59 AM, David Cole wrote:
>> But with your solution, *everybody* has to do work to achieve
>> non-duplication of very large data files when they do multiple builds
>> of VTK. *Everybody*.
>
> Previously, everybody had to checkout VTKData and perhaps VTKLargeData.
> Actually that is still true because we haven't converted test inputs yet.
>
> ITK has been getting along for over 2 years without an external default.

That doesn't preclude making changes for the VTK community in the VTK
repository. ITK has several differences in their repository layout,
modularization and development workflow.
>
>> I thought the whole main point of ExternalData was to download each
>> item needed *exactly* *once* and to enable non-duplication of each item.
>
> No, the main point of ExternalData is to version the data with the
> source without keeping the large files in the repository.  A shared
> persistent data store is an *optimization*.

Still, detecting a directory named ExternalData next to the source
tree, and using that if present wouldn't present a major technical
hurdle and seems like a great convenience that many of us have become
accustomed to. That would just make the optimization a little more
accessible. Is there a specific reason why looking for a known sibling
directory is such a bad idea? We could also have a more meaningful
cache variable that simply forces the generic variable to make this a
little more obvious when looking at the cache too couldn't we?

Marcus



More information about the vtk-developers mailing list