Re: lilypond source and music sheet database
Thanks Joseph for pointing me to git checkouts..it works for me. On Sun, Apr 7, 2013 at 7:42 PM, pls wrote: > On 07.04.2013, at 19:29, Joseph Rushton Wakeling < > joseph.wakel...@webdrake.net> wrote: > > On 04/07/2013 06:51 PM, Stjepan Horvat wrote: > > I realy like git too..Once i tried to make my own git server on my private > web-server so when i finish the work i can send the customer his pdf folder > link..but..that didnt work becouse you cant see actual files on git web > server..like you can on github.. > > Check out http://gitlab.org/. > > hth > patrick > > > In principle that's perfectly possible, you just have to set up the git > repo on > your web server to be a fully-fledged repo (i.e. has checked out files) > rather > than the bare-bones repo it tries to create by default. > > The trouble with that is that git (rightly) is cautious about allowing you > to > push to a remote repo with files checked out, so you can't just create a > regular > repo and push to it. > > There are a number of ways round this -- here's one I came across just > today: > http://toroid.org/ams/git-website-howto > > > ___ > lilypond-user mailing list > lilypond-user@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-user > > > -- *Nesmotren govori kao da mačem probada, a jezik je mudrih iscjeljenje. Izreke 12:18* ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: lilypond source and music sheet database
On 07.04.2013, at 19:29, Joseph Rushton Wakeling wrote: > On 04/07/2013 06:51 PM, Stjepan Horvat wrote: >> I realy like git too..Once i tried to make my own git server on my private >> web-server so when i finish the work i can send the customer his pdf folder >> link..but..that didnt work becouse you cant see actual files on git web >> server..like you can on github.. Check out http://gitlab.org/. hth patrick > > In principle that's perfectly possible, you just have to set up the git repo > on > your web server to be a fully-fledged repo (i.e. has checked out files) rather > than the bare-bones repo it tries to create by default. > > The trouble with that is that git (rightly) is cautious about allowing you to > push to a remote repo with files checked out, so you can't just create a > regular > repo and push to it. > > There are a number of ways round this -- here's one I came across just today: > http://toroid.org/ams/git-website-howto > > > ___ > lilypond-user mailing list > lilypond-user@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: lilypond source and music sheet database
On 04/07/2013 06:51 PM, Stjepan Horvat wrote: > I realy like git too..Once i tried to make my own git server on my private > web-server so when i finish the work i can send the customer his pdf folder > link..but..that didnt work becouse you cant see actual files on git web > server..like you can on github.. In principle that's perfectly possible, you just have to set up the git repo on your web server to be a fully-fledged repo (i.e. has checked out files) rather than the bare-bones repo it tries to create by default. The trouble with that is that git (rightly) is cautious about allowing you to push to a remote repo with files checked out, so you can't just create a regular repo and push to it. There are a number of ways round this -- here's one I came across just today: http://toroid.org/ams/git-website-howto ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: lilypond source and music sheet database
Hej thank you for all your anwsers.. I realy like git too..Once i tried to make my own git server on my private web-server so when i finish the work i can send the customer his pdf folder link..but..that didnt work becouse you cant see actual files on git web server..like you can on github.. > It's bit more complicated to set up, but wouldn't a good solution be to have a > separate repo for built files, and add a system that tracks when commits are > pushed to the source repo, and then automatically builds, and commits the output > to the build repo? You could use the --author, --date etc. options to git > commit to ensure the details match. I would realy like to see this working..and if it would be possible to add maybe a revision at the end of the pdf name..so if i have a mistake (and i have) when i change it people watching the folder can see that this is one new-er version..do you think that this is possible using only git or i would have to use make too? Maybe it would be a good feature..and could it be possible to make this binary repo surfable?! or evaen to upload using some bash scripts..i wouldn't mine..:) On Sun, Apr 7, 2013 at 3:01 PM, Joseph Rushton Wakeling < joseph.wakel...@webdrake.net> wrote: > On 04/07/2013 09:23 AM, David Kastrup wrote: > > 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. > > No. I did take a look inside them before writing my previous email -- they > certainly have more multi-line, plain-text content than some other PDFs > I've > worked with, so they'd probably compress/diff better than some files I've > worked > with. > > Most of my experience here is with PDF/EPS files coming out of gnuplot, > where > the PDF output tends to have a large amount of what seems to be > difficult-to-diff content, whereas the EPS files are almost entirely > plain-text > and so diff very nicely indeed. > > > Packing actual executables could possibly also work with reasonable > > overhead. > > Never tried, I'm afraid. :-( > > > 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. > > It's bit more complicated to set up, but wouldn't a good solution be to > have a > separate repo for built files, and add a system that tracks when commits > are > pushed to the source repo, and then automatically builds, and commits the > output > to the build repo? You could use the --author, --date etc. options to git > commit to ensure the details match. > > So, then you should have two mainline version histories that are > absolutely in > sync, allowing you to do the regression-tracking you're looking for but > without > blowing up the overall version history size for the source tree. > > But, bearing in mind that the on-disk size of the PDF docs is about 50MB > (as > reported by aptitude show lilypond-doc-pdf) and that of the HTML docs is > about > 90MB, then even allowing for some diffability of that material you'll be > seeing > a hefty cost to keeping those files versioned. > > I imagine that most of the disk-space cost of the HTML docs is actually > PNG or > other binary graphics files, which in my experience are the really nasty > ones to > version. > > On the other hand, some people apparently use git to version their home > directory, so perhaps it doesn't scale quite as badly as I think ... > > http://entrenchant.blogspot.it/2011/03/using-git-to-synchronize-and-backup.html > > The other problem you can face with source and binaries versioned in the > same > tree is simply that sometimes people will make a tweak to a source file > but not > rebuild before committing. And you can imagine the converse happening -- > someone making a tweak to source, rebuilding, finding it doesn't work so > not > committing the source, but accidentally committing the built file ... > > ___ > lilypond-user mailing list > lilypond-user@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-user > -- *Nesmotren govori kao da mačem probada, a jezik je mudrih iscjeljenje. Izreke 12:18* ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
tracking lilypond builds with git (was: lilypond source and music sheet database)
Hi, 2013/4/7 David Kastrup : > Janek Warchoł writes: > >> 2013/4/7 David Kastrup : >>> 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. > > find -name .gitignore -delete > > There is a wagonload of them in a typical LilyPond tree. Or: > > The git add command can be used to add ignored files with the -f (force) > option. That did the trick, i'm able to track things now. However, the results aren't very encouraging - here are the stats of the .git repository directory after several stages: after first configure: 513 items, totalling 656.8 kB after building master (25580682a): 5,010 items, totalling 59.2 MB after building 473a73eeb (30 commits away): 5,377 items, totalling 91.4 MB after building f1689df7a (1 commit away from master, and a small one) 5,580 items, totalling 112.3 MB ..so it's growing quite fast. According to http://stackoverflow.com/a/3055693/2058424 (and the linked email, over which i've skimmed) there may be some remedy for this, but it's not plain to me how exactly it should be done, and i'm out of time for testing now. However, i'd be very interested in seeing a solution for this (i.e. how to efficiently store lily executables in a repository). best, Janek ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: lilypond source and music sheet database
On 04/07/2013 09:23 AM, David Kastrup wrote: > 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. No. I did take a look inside them before writing my previous email -- they certainly have more multi-line, plain-text content than some other PDFs I've worked with, so they'd probably compress/diff better than some files I've worked with. Most of my experience here is with PDF/EPS files coming out of gnuplot, where the PDF output tends to have a large amount of what seems to be difficult-to-diff content, whereas the EPS files are almost entirely plain-text and so diff very nicely indeed. > Packing actual executables could possibly also work with reasonable > overhead. Never tried, I'm afraid. :-( > 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. It's bit more complicated to set up, but wouldn't a good solution be to have a separate repo for built files, and add a system that tracks when commits are pushed to the source repo, and then automatically builds, and commits the output to the build repo? You could use the --author, --date etc. options to git commit to ensure the details match. So, then you should have two mainline version histories that are absolutely in sync, allowing you to do the regression-tracking you're looking for but without blowing up the overall version history size for the source tree. But, bearing in mind that the on-disk size of the PDF docs is about 50MB (as reported by aptitude show lilypond-doc-pdf) and that of the HTML docs is about 90MB, then even allowing for some diffability of that material you'll be seeing a hefty cost to keeping those files versioned. I imagine that most of the disk-space cost of the HTML docs is actually PNG or other binary graphics files, which in my experience are the really nasty ones to version. On the other hand, some people apparently use git to version their home directory, so perhaps it doesn't scale quite as badly as I think ... http://entrenchant.blogspot.it/2011/03/using-git-to-synchronize-and-backup.html The other problem you can face with source and binaries versioned in the same tree is simply that sometimes people will make a tweak to a source file but not rebuild before committing. And you can imagine the converse happening -- someone making a tweak to source, rebuilding, finding it doesn't work so not committing the source, but accidentally committing the built file ... ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: lilypond source and music sheet database
Janek Warchoł writes:
> 2013/4/7 David Kastrup :
>> Joseph Rushton Wakeling 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.
find -name .gitignore -delete
There is a wagonload of them in a typical LilyPond tree. Or:
The git add command can be used to add ignored files with the -f (force)
option.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: lilypond source and music sheet database
2013/4/7 David Kastrup :
> Joseph Rushton Wakeling 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
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: lilypond source and music sheet database
Joseph Rushton Wakeling 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
Re: lilypond source and music sheet database
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.
So, if you keep updating the version of a particular binary file, you wind up
with a repo whose size is out of all proportion to the size of the checked-out
tree :-(
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: lilypond source and music sheet database
> Hi,
>
> 2013/4/6 Stjepan Horvat :
>> Hey guys .. what would you prefer using as a lilypond database. I have bunch
>> of files in bunch of folders laying around my pc with diferent versions of
>> the same song, 20 same/diffrent config files, unsorted and some of them
>> already are lost or can't find. Call it as a local "publishing" thing. I was
>> using git but they say it is not good for binary (pdf) files..it is for
>> programming..i want something where i can look for something i made 2 years
>> ago. What are your solutions..?!
>
> I am using git and i'm *very* happy about it. Git can be used for
> everything, binary files too. Of course, the problem with pdfs is
> that they cannot be easily diffed, but that's not particular to git -
> i don't think other VCS do better in this regard.
>
> 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.
>
> hope this helps you,
> janek
>
> PS depending on your experience with VCSes (and your OS) Mercurial
> might be a better choice sometimes.
Hi,
I don't know if this will be useful, but this is just a small comment
(somewhat off topic) on my (small) experience with this kind of
things.
For a project I currently work on (a set of songs and hymns that we
are still heavily modifying and arranging), I did set up a mercurial
repository, to keep track of all the changes in the ly files.
I decided not to track the pdf and midi files, but I did some
makefiles and shell scripts to ease the compiling of the whole project
(this part is easier on linux-like systems I guess).
With this system set up on a server, I can have the relevant pdf and
midi files compiled and published to a www folder whenever a
contributor pushes some changes on the repository (thanks to some
mercurial hooks, that can run a script on a given event).
I chose mercurial mainly because it works well on win systems, with a
gui, so it can be easier to use in our team, for non-technical users
that are unlikely to use linux. Second reason was the possibility to
set up hooks to manage the automatic compilation thing.
(then I discovered several fancies extensions that were adding useful features).
Anyways, even if this is probably too complicated for most uses,
managing source versions of scores with a version control system is
really helpful even for day to day use (though it implies a bit of
learning at the beginning). I would say makefiles are really useful as
well when working on multi instrumental scores (managing instruments
parts ans so on).
Good night !
If the system described is interesting someone, I can give more details on it.
Yann
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: lilypond source and music sheet database
Hi,
2013/4/6 Stjepan Horvat :
> Hey guys .. what would you prefer using as a lilypond database. I have bunch
> of files in bunch of folders laying around my pc with diferent versions of
> the same song, 20 same/diffrent config files, unsorted and some of them
> already are lost or can't find. Call it as a local "publishing" thing. I was
> using git but they say it is not good for binary (pdf) files..it is for
> programming..i want something where i can look for something i made 2 years
> ago. What are your solutions..?!
I am using git and i'm *very* happy about it. Git can be used for
everything, binary files too. Of course, the problem with pdfs is
that they cannot be easily diffed, but that's not particular to git -
i don't think other VCS do better in this regard.
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.
hope this helps you,
janek
PS depending on your experience with VCSes (and your OS) Mercurial
might be a better choice sometimes.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
lilypond source and music sheet database
Hej guys..what would you prefer using as a lilypond database. I have bunch of files in bunch of folder laying around my pc with diferent versions of the same song, 20 of same/diffrent config files, unsorted and some of them i already can't find. Call it as a local "publishing" thing. Hey guys .. what would you prefer using as a lilypond database. I have bunch of files in bunch of folders laying around my pc with diferent versions of the same song, 20 same/diffrent config files, unsorted and some of them already are lost or can't find. Call it as a local "publishing" thing. I was using git but they say it is not good for binary (pdf) files..it is for programming..i want something where i can look for something i made 2 years ago. What are your solutions..?! -- *Nesmotren govori kao da mačem probada, a jezik je mudrih iscjeljenje. Izreke 12:18 * ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
