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

Bill Lorensen bill.lorensen at gmail.com
Wed Mar 6 10:23:12 EST 2013


For ITK, we started with submodules for the data and after a few months
abandoned it. We had too many situations where the submodules got screwed
up because a developer did not follow the proper protocol. I can't recall
the details.

I suggest we keep things as they are until we switch over to a content
based hashing we use in ITK. Which, my the way, works great.


On Wed, Mar 6, 2013 at 10:19 AM, Marcus D. Hanwell <
marcus.hanwell at kitware.com> wrote:

> 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
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://www.vtk.org/mailman/listinfo/vtk-developers
>
>


-- 
Unpaid intern in BillsBasement at noware dot com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20130306/e1297bcd/attachment.html>


More information about the vtk-developers mailing list