Hi Ernesto, hi Robin,
thanks for your replies.
The thing I like most with your solution is that svnversion provides a modify flag, so I can see whether all changes have been cheched in. Great.
A little drawback is that all files under the current path are used to determine the version. If theres a file in the path which is not part of the document changes to this file will also change the revision of the document. But I think this can be easily prevented by placing every document into an own directory.
What do you think of using:
\def\SVNVERSION{svnversion -n > svnversion.tex}
\ifeof18 \installprogram{\SVNVERSION}% \else \executesystemcommand{\SVNVERSION}% \fi
That is nicer of course ... I just do it outside the document in a Makefile because I'm used to doing that sort of thing. I imagine the only uncompromised way to extract an svn revision (or revision range) that covers the whole document accurately is to write a script that extracts the source file names from the previous logfile (or somewhere), individually determines their revision using "svn status" (to get modified status), and constructs an overall result. I guess some embedded Lua could do that pretty easily and portably. It would also catch files that are often outside the immediate document directory (in particular, bib files).
Ernesto Schirmacher schrieb:
If your sources are in svn, then they actually have the same svn- number, after a commit. But the numbers in the $Revision$ or $Id$ tags of your working copies are not updated by svn commit. However, if you do an "svn update" after the commit, it should update the numbers.
This is not true. The complete name of $Rev§$ is $LastChangedRevision$. It's the revision of the last change to this file.
Quite right, my apologies. An "svn update" does however alter the output of "svnversion", for instance if it indicates a mixed revision (1234:3456), after an update it will be just 3456. Best, Robin