On 02.01.2010, at 20:49, Carl Sorensen wrote:
May I suggest that the proper way to handle this is not to try to turn
LilyPond into an information manager?
Instead, the proper way is to use an information manager with
LilyPond.
I would recommend that the semantically appropriate way to handle
this is to
stop thinking of a piece as a single file, and instead, think of it
as a git
repository (or the equivalent, but I think git is *perfect* for this
application).
Each different edition is a different branch on the tree, and the
LilyPond
file *for that branch* is changed, but the original manuscript file
is still
available in the master branch.
Changes in the manuscript file can be applied to each branch via git's
patching algorithms. And if desired, custom git commands that will
automatically apply changes to the source manuscript to every other
edition
could be created.
Each different edition is then available as a branch, to be run
through
LilyPond at any desired time.
And the changes between the different editions are easily available
through
the git diff command.
HTH,
Carl
That is a brilliant idea, and an actual reason for me to try and
learn how to use git.
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
