Joseph Rushton Wakeling <joseph.wakel...@webdrake.net> 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
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
