PDF versioning

[jdaw1]

From a long-lost question on ThePortForum.com, and subsequently asked on comp.lang.postscript:

There have been few instances of an old version of the PDF being printed, perhaps because of caching problems. One solution — rejected for this problem — would be to have many separate file names. Not good: there should be a single canonical-seeming file name; and the drafts should not have a permanent life. A different technique is something I don’t know how to do. In the PDF, presumably added via pdfmark, could there be something like the following pseudocode?

On Open
{
	If Today ≤ HardWiredDateConstantBeingDateOfTasting
	{
		MessageBoxPopUp 
			string="This version HardWiredStringConstant: check that is latest with a force-reload."
			Buttons={"OK, checked"}
	}
}

Help implementing would be much welcomed.

[phwakely]

You may be asking two separate questions, I'm not sure whether one or both:

1. Does the PDF document format provide some form of inherent document version attribute which we should set, and if so how?
2. Does GIT allow us to ensure that any checked-out copy of the postscript from the GIT repository is uniquely identifiable, ideally using some form of version numbers?

I will have to leave (1), if relevant, to others.

Regarding (2) this was something easily available when using SVN repositories, where the string "$Revision: $" could be included within any text file in the repository (such as your postscript file); on every check-in to the SVN repository (even on branches) a linear counter would increment, and whenever a file is checked out the "$Revision: $" field is replaced with the revision of the repository on which that file last changed. For your postscript single-file this would be ideal.

Unfortunately, while GIT does maintain a check-in counter, it does not provide the ability to insert/replace this in a checked out file. The usual procedure when this is used with a software build is for an external query to the GIT repository to check the value at that same time as performing the clone (checkout) and write this to a file which then gets included in the build; however your project is not a standard software project with build environment, so pre- and post- commands within scripts or makefiles would not be appropriate.

The only thing I am aware of that you could do would be to include the "$Id: $" string which GIT does support, and which is replaced by a unique value defining the position on the repository at time of checkout, but the unique value is a SHA-1 hash, i.e. an alphanumeric sequence such as "$Id: e184834e6757aac77fd0f71344934b1cd774e6d4 $". While this would still allow you to track back to a specific instance within the repository if needed, it's certainly not user-friendly.

You may wish to manually set/incrementing a version X.Y in the text file anyway; I will commonly use a format of major/minor/build in software development, where major/minor are set manually when wanted to be incremented or on every official/external release, while the "build" value is the SVN check-in count (or GIT equivalent using some scripting).