"Phil Holmes" <m...@philholmes.net> writes: > I've got a couple of weeks off college now and could look at this. My > knowledge of python is small and git even smaller, but would be happy > to make changes and test them. Would clearly need the help of the > people who know what they're doing, tho'. > > I've not looked at the attached file, but what were you trying to do > and what caused problems, Jan?
I have not looked either. The outline of the work as I understand it and would tackle it would be a) git management. test-patches.py basically takes whatever state its reference repository index is at as its starting point. In contrast, the staging patchy is pretty careful to rely not at all on whatever you happen to have checked out in which state in the reference repository. b) work tree management. test-patches.py checks out a git tree, makes a test baseline, then applies each of a sequence of patches, tests it against baseline, then reverts the patch again, does some sort of cleanup and continues to the next. That's a bad idea: it should rather wipe everything clean for the next patch and do a fresh checkout. Which would remove the test baseline, so we come to the next point: c) test baseline management. Since the test baseline output sits in directories with a certain filename, it is reasonably easy to move the baseline results somewhere else (it would probably make sense to create a separate directory with tar files with the commit id of the baseline in its filename, in a directory used for such baselines, and only leave files in there that have been used lately). That way, each test baseline is created only once and can be shared between staging patchy and testing patchy. This would also mean that if some patch requires testing against some other baseline (or you want to catch a regression reasonably fast by comparing against a number of baselines), this would not require recompilation of the particular test baseline. I think that Janek has been working on sanitizing step b) by making the reversal of patches more reliable, but probably this would become easier if c) was tackled first and thus it became feasible to do a complete brainless wipeout as step b). -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel