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
<address@hidden> 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 ...
--
Nesmotren govori kao da mačem probada, a jezik je mudrih iscjeljenje. Izreke 12:18