<div dir="ltr"><div style>Hi Marcus, </div><div style><br></div>+1 <div>Rebase looks like a good trade-off. Thanks looking into alternative to submodule. </div><div><br></div><div style>Jc</div></div><div class="gmail_extra">

<br><br><div class="gmail_quote">On Fri, Mar 8, 2013 at 11:23 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>
We had a discussion about possible solutions to the baseline images<br>
changing in master, whilst I think we all agree that external data<br>
using the process developed for ITK is the ideal solution we do not<br>
currently have the time/resources to accomplish this. It also looks<br>
like there was widespread rejection of using submodules as an interim<br>
solution, and rebasing/merging master in was suggested.<br>
<br>
After looking into that I don't think it is a viable solution, or it<br>
would require more work than I first realized to make it work. Perhaps<br>
Brad may know of a clever solution I didn't see, but making ctest<br>
merge/rebase and correctly report merge conflicts does not appear to<br>
be easy - I even dug into the C++ code in CMake looking for a better<br>
solution. As regression images for existing tests don't happen that<br>
often I would like to propose a simpler, although perhaps less<br>
satisfying solution...<br>
<br>
If you submit a topic to Gerrit for review and it has apparently<br>
unrelated test failures and you/the reviewers are worried about this<br>
then rebase and push again. I would like to strongly discourage<br>
abandoning a topic and creating a new one for the rebase, while<br>
rebasing makes it difficult to see what really changed disconnecting<br>
reviews across multiple topics is far worse in my opinion.<br>
<br>
I would rather not spend too much time coming up with a clever<br>
solution to creating temporary merged heads with possible<br>
conflicts/reporting these to the dashboard when we already have a good<br>
technical solution to this problem - content based hashing using<br>
external data. Feel free to swoop in with something cleverer and<br>
easier that I missed though ;-)<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>+1 919 869 8849<br>
</div>