Re: lilypond source and music sheet database

[David Kastrup]

Joseph Rushton Wakeling <address@hidden> writes:

> On 04/06/2013 10:50 PM, Janek Warchoł wrote:
>> The things is, use git for tracking source files, not pdfs.  If you
>> put \version statements in all your .ly files, you can always recreate
>> a pdf with appropriate LilyPond version.
>> 
>> Actually, it might make sense to track some pdfs as well, but i'd say
>> only the versions that are somewhat final, and i'd create two
>> repositories: one with sources, in which all pdfs would be ignored,
>> and another one with finished ("published") versions of pdfs - ones
>> that are supposed to change rarely.
>
> Good call.  The trouble with versioning binary or binary-ish files is
> not so much about diffs in the sense of being able to see what has
> changed (e.g. bzr with the qbzr plugin does nice side-by-side before
> and after comparison of graphics files) but that because it can't be
> diff'd, each new version almost always adds an amount of data the size
> of the entire file to the version history.

Have you tried with LilyPond PDFs?  I think they tend to compress on the
object level which _might_ work reasonably with some of git's packing
techniques.

Packing actual executables could possibly also work with reasonable
overhead.

There would be an advantage to a repository storing _complete_ compiled
versions of LilyPond: it would make "git bisect" for the purpose of
finding a regression in code or documentation a snap.

-- 
David Kastrup