
<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><br></div><div><div>On Jun 21, 2013, at 4:41 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite">The reason I want a flag is to avoid the need to update the existing testing<br>cases while this is a work in progress.<br>I believe migrating one field means updating the existing testing cases?<br></blockquote><br>It would, yes - and that's how you'd get coverage to know your change<br>was stable. You'll have to update all the tests eventually anyway &<br>doing so incrementally isn't substantially more expensive in my<br>experience. Perhaps there's something unique to this migration that<br>would make it so?</div></blockquote></div><br><div>I am going to update the existing testing cases locally to have the test coverage, but I don't want to check in the changes often.</div><div>Once we turn the flag on by default and remove the other path, I will submit the changes on the testing cases.</div><div><br></div><div>Another point to have a flag is to check in the patches in steps: DIBuilder changes, changes related to the map, and DwarfDebug changes.</div><div>Without the flag, when I migrate the first field, I have to make sure it works from frontend all the way to the backend.</div><div><br></div><div>Hopefully that makes sense.</div><div><br></div><div>Thanks for all your help,</div><div>Manman</div></body></html>