On Sunday 02 May 2004 23.00, Han-Wen Nienhuys wrote: > Couldn't we just have the entire collection rendered just like > input/test in the tips & tricks? Putting binary blobs, which are also > compiler output (by lilypond), into a source version control system > isn't the way to go I.M.O.
I see the pngs only as an illustration to the bug description. Different pngs may be created in different ways, see e.g. grace-accidental-spacing.png. The reason why most pngs are direct lilypond output, is that this often is the easiest & clearest way of doing it (but it would work just as well e.g. to draw a picture of lilypond's output by hand) There are 2 reasons they are there: 1. To make it more obvious to you developers what I mean 2. That I will be able to easily compare the .ps output of new versions to the old buggy output, so I quickly can decide whether the bug has been fixed. What you describe is AFAICU some kind of history of how layout bugs evolve between lily versions. I have not seen any use for this myself yet. Bugs tend to be binary; first it doesn't work, then it works; so in this case the only relevant history is contained in the date the bug was removed from CVS. I agree that using cvs for uploading png may seem a bit strange. But it works and is very simple. "cvs add -kb foo.png" is much easier than using ftp. And the file will be downloaded automatically to . during cvs update, which is much easier than having to open mozilla. I'll be happy to change the system once there is a really good reason for it, though. Erik _______________________________________________ bug-lilypond mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-lilypond
