> 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