<div class="gmail_quote">On Mon, Sep 17, 2012 at 9:44 AM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":2tm">One reason I like everything in one file/place is that now lots of "test" examples are in the "tutorial" directories. To move them requires:<br>
<br>
1)  hg move the example code<br>
2) hg move several output/* files<br>
3) edit the "tutorials" makefile to remove stuff<br>
4) edit the "test" makefile to add the stuff<br>
<br>
  and plus since there will be name conflicts for source code names one will also need to change, for example, ex1.c to ex37.c in all these places.<br></div></blockquote><div><br></div><div>I think the dumb numbers were a bad idea in the first place. There are way too many examples that are ("this is a less maintained copy of some other Bratu example"). How are we going to update inline output? We could write an Emacs minor mode that updated it on file save, but to keep file save fast enough, the output would have to be lying around. We'd also have to be careful not to accidentally check in bad output. I hate the idea of having to manually copy and paste into some piece of the output.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":2tm">
  If everything was in one file I could just hg move that one file to the new location (changing the name of the file if needed). Sooo much easier. Why do you think no one has fixed the cluster fuck we have currently.</div>
</blockquote></div><br><div>What about storing a SHA1 of the reference output in the source file (or wherever the test was specified). Then have one big store of outputs for everything, indexed by SHA1. The output store need not even be part of the Hg checkout, it could be stored in a separate repository. When reference output is updated, a new file is created in the archive and the SHA1 at the test specification is updated. We could make a more convenient diff tool, but this allows moving files around willy-nilly, including taking them entirely outside of PETSc, without needing to futz with the test output files.</div>
<div><br></div><div>If we did something like this, I'd be more comfortable specifying tests with markup inside the source file (though I'd rather that not be the _only_ way to specify tests).</div>