Problem with svn-multi-package (\svnrev gives false revision number)
Lvood
therefore created a svn repository for my files and used the latex
package for inserting version control information in my pdf document.
I have a latex main file Diss.tex which contains the preamble and the
titlepage etc. and source files for each chapter which are inserted in
the document with \include.
At first everything worked great, now I have the following problem:
Although the whole project now is revision 15, the command \svnrev
always shows revision 11 (revision of the main file).
I've checked the file Diss.svn and there is still \svnrev{11} defined,
though I've commited several times since revision 11.
Did anyone encounter similar problems or knows better knows how to
solve them?
Is it possible that svn-multi does not know which *.tex files to
"monitor" when creating the auxiliary file Diss.svn?
Kind regards
Martin
Alan Ristow
Without a minimal example that demonstrates the problem I'm only
guessing, but have you done *all* of the following:
- Set the svn keyword property for *each* of the tex files included in
your document? (How you do that depends on the tool you use to manage
your svn repository.)
- Properly included the \svnid command in *each* of the tex files
included in your document?
- Recompiled the document *twice* to ensure the document revision number
propagates where it needs to?
I, for example, set the svn keywords for every file I add to my
repository to:
Id Author Date Rev URL
Then I put the following at the top of every tex file in my document:
\svnidlong
{$HeadURL$}
{$LastChangedDate$}
{$LastChangedRevision$}
{$LastChangedBy$}
\svnid{$Id$}
You might use different keywords and syntax depending on exactly what
svn information you want access to from within your document, but this
works well for my purposes.
Alan
Stephan Hennig
> Did anyone encounter similar problems or knows better knows how to
> solve them?
Not related to svn-multi only, but to LaTeX and version control in general:
There is an inherent problem with LaTeX and version control software as
soon as you're dealing with files generated by an external tool, e.g.,
graphics. Packages such as svn-multi can't track those files even if
they are not binaries, but have been compiled by, e.g., MetaPost,
since LaTeX doesn't read those source files. That is, if you check-in a
new revision that only touches a graphic file, your VCS package would
never know a check-in has taken place and tell you the old revision
number in your documents.
The problem is only temporary and as soon as you check-in a file that is
tracked by the VCS package, i.e., a .tex file, you'll get the correct
revision number again. But according to Murphy, no doubt, you're giving
away a document with a wrong revision number.
To enable reliable tracking of revision numbers (or other meta data) one
has to look at /all/ files in the working copy. I have written AWK
scripts that talk with Subversion or Git to get the desired information
(quite a different approach to existing LaTeX VCS packages, working
without keyword substitution). The scripts work quite well for me, but
documentation is completely missing. That's why I've never uploaded
them to CTAN.
Here's a short how-to:
Installation
--------------------------------------------
1. Install an AWK interpreter. For Windows you can find one in the
GNUWin332 utilities.
2. Download the vc package at
<URL:http://home.arcor.de/stephanhennig/Downloads/vc-0.1alpha.zip>.
3. Put the files
vc-svn.awk
vc (bash script)
vc.bat (Windows 2000 or later batch script)
into your working copy directory. Personally, I've checked those files
into my project repositories to have them available when needed.
Optionally: you can instruct your VCS software to ignore the
automatically generated file vc.tex (for Subversion see property
svn:ignore, for Git see .gitignore).
Usage
--------------------------------------------
1. Add the line
\input{vc}
to your LaTeX (or plain TeX) document.
2. Before compiling a document execute the script file vc (or
vc.bat for Windows). This generates a new file vc.tex that contains the
VCS related information. Inside your document you can now use the
following macros
\VCRevision - current (maximum) working copy revision number
\VCRevisionMod - as \VCRevision, but with an additional note if
the working copy contains modified files
(The actual note is defined in macro \VCModifiedText
and can be redefined by the user.)
\VCAuthor - author of the last check-in operation
\VCLongDate - date and time of the last check-in
\VCDate - date of the last check-in in ISO format YYYY-MM-DD
\VCDateTeX - date of the last check-in in TeX format YYYY/MM/DD
\VCTime - time of the last check-in
There are additional meta data available, depending on the VCS software.
Those macros are prefixed \SVN or \GIT (see file vc.tex), but the \VC
macros are available for both systems and in general should be sufficient.
I can hear the question "Do I need to run vc(.bat) every time the
document is compiled?" Yes and no. To get the revision number it is
sufficient to run the script after a check-in or update operation. The
only advantage of running the script before every compilation is that it
keeps \VCRevisionMod up-to-date wrt local modifications. But since
compiling and distributing documents not freshly checked-out is bad
style anyway, I prefer using \VCRevision over \VCRevisionMod anyway.
The recommended way to work with the script is either by adding it to a
Makefile or by running the script by LaTeX via the write18 switch. (I
have not tested the latter method. If you don't know what is meant by
write18, please consult you LaTeX documentation of ask on this list.)
Comparison with other VCS packages for LaTeX
--------------------------------------------
* Looks at /all/ files in a working copy to get
reliable revision information.
* Works with LaTeX and plain TeX.
* Works with Subversion and Git.
* Doesn't need keyword substitution.
* Needs an AWK interpreter.
* Running the script might become noticeable on projects with
many files.
Comments are welcome!
Happy TeXing!
Stephan Hennig
mpg
> Is it possible that svn-multi does not know which *.tex files to
> "monitor" when creating the auxiliary file Diss.svn?
>
svn-multi doesn't "monitor' files: it justs executes the \svnid macro when
you ask him to.
As Alan said, it's best to give a minimal example so we can see the problem
(two 5-lines files are enough). Check the points he mentionned, and post an
example if it still doesn't work.
Another possible explanation: due to a bug in the current version, \svnid
will only work correctly before the \begin{document} if you are writing in
french with babel... (I told it to the author a few days ago.)
Manuel.
Alan Ristow
> Lvood schrieb:
>
>> Did anyone encounter similar problems or knows better knows how to
>> solve them?
>
> Not related to svn-multi only, but to LaTeX and version control in general:
>
> There is an inherent problem with LaTeX and version control software as
> soon as you're dealing with files generated by an external tool, e.g.,
> graphics. Packages such as svn-multi can't track those files even if
> they are not binaries, but have been compiled by, e.g., MetaPost,
> since LaTeX doesn't read those source files. That is, if you check-in a
> new revision that only touches a graphic file, your VCS package would
> never know a check-in has taken place and tell you the old revision
> number in your documents.
That is an excellent point! I had not even considered that, since every
last one of my graphics in all of the projects I have ever put under
version control were only checked in as in-line PSTricks source code
(Metapost users can, I believe, use the emp package to achieve something
similar). It wouldn't surprise me if this is precisely the problem the
OP is having, though.
Alan
Lvood
wrote:
Hi Alan,
thanks for your reply - I configured everything according to the svn-
multi documentation by M. Scharrer, also added the lines
\svnidlong(...) at the beginning of each tex file and set the svn
properties in the terminal for all *.tex files.
I have found the problem: as mpg mentioned, the problem is the french
babel package - when I do not load it, everything works fine.
Kind regards
Martin
Lvood
Salut Manuel,
thanks a lot - you saved me!
After deactivating the french babel package, it seems to work fine
now!
I'm not writing in french, but as I had a french translation of the
abstract in my diploma thesis, I had still included the french package
in my phd thesis template, but fortunately don't need it absolutely at
the moment.
Kind regards et bonne jounée
Martin
mpg
> thanks a lot - you saved me!
> After deactivating the french babel package, it seems to work fine
> now!
Cool.
> I'm not writing in french, but as I had a french translation of the
> abstract in my diploma thesis, I had still included the french package
> in my phd thesis template, but fortunately don't need it absolutely at
> the moment.
>
In case you need french again, I am using the following patch, which works
fine:
\makeatletter
\renewcommand\svn@catcodes{%
\let\do\@makeother \dospecials
\catcode`\^^M9 \catcode`\ 10
\catcode`\{1 \catcode`\}2 }
\makeatother
The problem is, frenchb changes the catcodes of :;!? and, since
\svn@catcodes was using its own list of special characters instead of
\dospecials, it missed that point.
Bonne journée,
Manuel.
Martin
I integrated this patch now in the svn-multi package. Thank you very
much for it.
I'm very busy at the moment so I can't test it as much I should.
I uploaded the changed package under:
http://www.skynet.ie/~mscharrer/svn-multi.sty
It would be great if you all could check if this version would fix
your problems, i.e. if the patch got correctly applied.
I still have to check if this isn't breaking other features of the
package.
Thanks,
Martin