Re: lilypond source and music sheet database

[Janek Warchoł]

2013/4/7 David Kastrup <address@hidden>:
> 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.

Hmm.
Some time ago i've tried creating a repository containing lily builds,
but somehow i wasn't able to tell git to actually track all files - it
seemed that majority of them were ignored.

Janek