Revision 2, book.pdf to be frozen

[friendly]

I'm getting ready to prepare the current revision2 version of the book and submit it to the publisher. My target date is Monday, Sept. 14, but certainly by Sept. 16, when I hope to submit.

To date, AFAICS, nearly all global and all local copy edits have been dealt with; @mattsigal finished what can be done on conversion of RGB in figures to CMYK; @sciencegraph completed tweaks of figure/table positions, at least through Chapter 8. I'm happy to leave any further page tweaks to the next round, but I would like to know if anyone has noticed any other problems that should be addressed before re-submission.

The steps to prepare the new book.pdf will be what is recorded in the file Make.R, that compiles with knitr, re-creates the author index, re-runs pdflatex, and finally embeds fonts in the book.pdf file.

My hearty thanks to everyone who has contributed to this project!

[sciencegraph]

Figures 3.8 and 3.12 seems to be unreferenced.

On 9/10/2015 6:10 PM, Michael Friendly wrote:

I'm getting ready to prepare the current revision2 version of the book and submit it to the publisher. My target date is Monday, Sept. 14, but certainly by Sept. 16, when I hope to submit.

To date, AFAICS, nearly all global and all local copy edits have been dealt with; @mattsigal https://github.com/mattsigal finished what can be done on conversion of RGB in figures to CMYK; @sciencegraph https://github.com/sciencegraph completed tweaks of figure/table positions, at least through Chapter 8. I'm happy to leave any further page tweaks to the next round, but I would like to know if anyone has noticed any other problems that should be addressed before re-submission.

The steps to prepare the new book.pdf will be what is recorded in the file |Make.R|, that compiles with knitr, re-creates the author index, re-runs pdflatex, and finally embeds fonts in the |book.pdf| file.

My hearty thanks to everyone who has contributed to this project!

— Reply to this email directly or view it on GitHub https://github.com/friendly/VCDR/issues/52.

[friendly]

Thanks. I'll fix that.

[friendly]

@philchalmers : When I've frozen the book.pdf in the past, I simply rename it to book-mm-dd-yy.pdfso that is retained.

• Is this the best way?
• Is there an advantage to add a tag? [I don't really understand their role.]
• Should we stick to the revision2 branch or add a new one?

[philchalmers]

On Mon, Sep 14, 2015 at 2:47 PM, Michael Friendly notifications@github.com wrote:

@philchalmers https://github.com/philchalmers : When I've frozen the book.pdf in the past, I simply rename it to book-mm-dd-yy.pdfso that is retained.

• Is this the best way?

It's fine practically, and in this case I see no gain replacing old files. The only downside is that it takes up more space on your hard-drive (pdfs of this size are treated as binary files, so two different version are compressed in the .git repo and tracked regardless of whether the file was copied or replaced....but the copy method will extract both pdfs when cloned, so it takes up a bit more room). Not really an issue these days unless someone is using a 10 GB hard-drive ;P

-

• Is there an advantage to add a tag? [I don't really understand their role.]

Tags are nice and would have been what I recommended had I joined the project before master was forked off. Essentially, you can interpret tags as a super-save operation, an archive file for easily building zip files (like CRAN) or seeing what the code-base was like at the time of the tag, or simply a flag indicating at which point you think the work has become 'stable'. Benefits of tags versus creating branches are: active branches looks more clear (git branch .... shows only working branches), tags get meta-commit messages, tags cannot be edited by accident (unlike branches), and repos like Github use them for downloading compressed files (e.g., https://github.com/philchalmers/mirt/releases). Tags can also turn into branches later, so you lose nothing by using them over branches.

Basically, the idea is to track exactly which commit should be considered as a stable version. If you tagged your repo at commit 100, did some work, and then later needed to roll back for some reason then when you checkout the tag (and use git log) your repo would look as though you've only done 100 commits because the history is saved exactly at that location. So in essence, they are like making a branch without making a branch.....but could turn into a branch if the need arose.

Back in time when all work was done on master, when it was time to freeze for revision1 you could have done

git tab -a rev1 -m 'First revision freeze' git push --tags

then just continue working on that branch knowing that you can always go back in time.

[EXTRA: If for some reason you needed to roll back to that tag to make a fork of edits, you just check out the tag and create a new branch (git checkout rev1; git checkout -b rev1-temp-branch) and edit. That's pretty rare though --- tags are usually just for reverse compatibility, comparability, and milestone tracking.]

• Should we stick to the revision2 branch or add a new one?

I would stick with revision2 at this point to keep the workflow the same for everyone; and just use a tag! Cheers.

Phil

— Reply to this email directly or view it on GitHub https://github.com/friendly/VCDR/issues/52#issuecomment-140172069.

[friendly]

I've now re-compiled the book, embedded fonts, and renamed book.pdf -> book-09-15-15.pdf to be the frozen copy that I'll submit for the next round of copy edits.

I'll submit this tomorrow, unless anyone finds problems that still need to be corrected.

[friendly]

@philchalmers : I'm not sure I understand all the details of using tags, but would it make sense now to do something like

git tag -a rev2-submitted -m "Revision 2 frozen and submitted"
git push --tags

[philchalmers]

Absolutely. So long as you make a tag now, we can deal with whatever else later. On Sep 18, 2015 10:41 AM, "Michael Friendly" notifications@github.com wrote:

@philchalmers https://github.com/philchalmers : I'm not sure I understand all the details of using tags, but would it make sense now to do something like

git tag -a rev2-submitted -m "Revision 2 frozen and submitted" git push --tags

— Reply to this email directly or view it on GitHub https://github.com/friendly/VCDR/issues/52#issuecomment-141471961.

[friendly]

OK, done.