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.<div>
<br></div><div>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.</div><div><br><br><div class="gmail_quote">On Wed, Mar 6, 2013 at 10:19 AM, Marcus D. Hanwell <span dir="ltr"><<a href="mailto:marcus.hanwell@kitware.com" target="_blank">marcus.hanwell@kitware.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
Berk and I were talking about the situation with VTKData and<br>
VTKLargeData when submitting topics for review. We know about the<br>
content based hashing used in ITK, but were thinking about adding<br>
VTKData as an optional git submodule to the VTK repository in the<br>
interim before we can invest the time required for a migration to what<br>
ITK uses.<br>
<br>
Advantages we see in this approach:<br>
 * Can be done in minutes<br>
 * Dashboards will continue to pass as expected when their data SHA is old<br>
 * These submodules would be entirely optional (as VTKData/VTKLargeData are)<br>
 ** Normal development would not require new steps<br>
 * Would allow for topics to definitely push data forward with new baselines<br>
 ** No asking people to make sure they do it once merged<br>
 * Git is now very good at resolving submodule conflicts - simple<br>
linear flow in VTKData<br>
<br>
Disadvantages:<br>
 * Still some situations where the baselines could get mixed up<br>
 * Some increased complication when pushing the submodule forward for<br>
new baselines<br>
 * Possible mixups in pushing submodule backwards, easy to spot in<br>
review/CDash@Home<br>
<br>
I think overall the process would be less error prone, and would take<br>
the last bit of guess work out of reviewing CDash@Home submissions (is<br>
it red due to being based on older master, with newer master<br>
containing updated test code or because they really broke something in<br>
this topic). I also think that git has matured to a level, and we have<br>
learned as a group where this solution is a reasonable short term<br>
solution. We can also simplify our instructions, and remove the<br>
question of where VTKData etc are located.<br>
<br>
Thoughts, objections, alternatives?<br>
<br>
Thanks,<br>
<br>
Marcus<br>
_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.vtk.org/mailman/listinfo/vtk-developers" target="_blank">http://www.vtk.org/mailman/listinfo/vtk-developers</a><br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Unpaid intern in BillsBasement at noware dot com<br>
</div>