TeX - LaTeX Stack Exchange is a question and answer site for users of TeX, LaTeX, ConTeXt, and related typesetting systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

For some time now I'm using pdfLaTeX for writing my job applications, which normally contain 3 pdf documents all created with LaTeX:

  1. the letter of motivation
  2. the CV and more information about my projects
  3. diploma, certificates, etc.

I now noticed that it would have been good to use version control of the different versions to document the differences or take notes about what was changed.

I already used version control with the svn-multipackage for my dissertation, but that is only a "linear" process where I save a "snapshot" and don't have different versions in parallel.

=> So what would be an appropriate workflow for SVN to handle those documents
under the following conditions:

  • it should be clear in the .tex source which document/version was taken as "template" for the actual file, but this shall not be visible in the pdf
    (to avoid the potential employer seeing "ah, this is application number 323a ...")
  • I'll create a directory for each application "somewhere" outside my svn repository,
    -> I think this would be done by an export of an existing version - is that correct?
    (That directory will also contain other documents with information about the company, the job etc., which will not be managed by svn)
  • If the documents are finished, is it correct to save them in the repository by 'update'?
  • How could I create different "main versions"
    (e. g. one focussing on jobs in IT business which puts more emphasize on my computer skills and another one for the more "technical" jobs where those computer skills are not shown in detail)
  • Would it be a problem for SVN if in the custom directory of each application I change the name of LetterOfMotivation.tex to LetterOfMotivation_CompanyXY.tex?
    I suppose when I do that and then send it back to the repository, SVN would be confused and not recognize the new document as a changed version of LetterOfMotivation.tex?

I'm sorry if that sounds like stupid questions, but I have no experience with the "real" use of svn up to now. :-(

share|improve this question
up vote 2 down vote accepted

A lot of questions!

Most of these have already been answered on TeX-SE, though

  1. I don't think there's a TeX solution for that, but you can write your own post-commit SVN hooks that modify all your source files, adding the version string, commit date, and whatnot as a comment in the beginning of each file. See this on how to create repository hooks. Admittedly, this is not for the faint of heart and you'll need to write a script or two.

    An alternative solution is to keep your SVN info as PDF metadata when you store them in the repository, and to strip it when sending it to an employer. Writing metadata is easy - see this question, for example. You might need something like pdftk (the definitive PDF manipulation tool) for the job, again with a small script.

  2. Yes, svn export is the way to do it if you don't want to have the SVN metadata in your exported tree (I do this when I'm sending stuff to people, or want to make changes that are not going back in the same branch/repo). You can always commit back the changes if you like, but all the information about previous revisions is lost in the exported tree.

  3. No! You issue svn commit to write your changes to the repository. svn update will update your local tree from the repository, which will wipe out all the changes you've made. For new files and directories not currently tracked by SVN, you have to do svn add first.

  4. This is a matter of maintaining different branches in the repository, which with SVN is more hassle than it's worth -- unless you don't care about merging them back, in which case it's fine. The SVN book has more information on branching and merging. If you do care deeply about branching, SVN is terrible at that -- Mercurial or another distributed version control system is does merging with considerably less pain.

  5. This is done by svn rename. Do not use the normal file renames that your operating system supplies, otherwise what SVN would do is to remove the first version and then add the other one, which is not what you want to do.

    But there is probably a better way to handle this: use SVN tags. Tags are simply more descriptive labels to specific revisions. For example, your program with 1.0 version is taken from revision 32167, and 1.1 is revision 33341. Instead of remembering revision numbers, you can use tags to check out exactly the code that was used to produce the particular version. You can do the same in your case -- add a tag for each revision you send to a company (e.g. Company XYZ-a, and then use the normal SVN mechanisms to retrieve a specific version you'd like to use.

Now that I'm looking at these answers, I'm more and more convinced that SVN is not the right revision control system for you. If you plan to do extensive branches and merges, and maintain a plethora of different versions simultaneously, Mercurial or git might be better choices. Here is the excellent Mercurial tutorial written by Joel Spolsky, that will explain in simple terms all you ever need to know about Mercurial.

share|improve this answer
thank you very much for your detailed answer! well, I'm not sure if I plan to do "extensive" branches and merges, but at least I'd like to easily compare the current version I'm working on with another one from the repository. Concerning branches: I'd have several different main versions (maybe 2 to 4) for different groups of employers (e. g. Research institute / industry 1 / industry 2 / IT industry), so I'd have to maintain 4 branches, I assume? I think it would not make sense to create a branch for every single company, or does it? – MostlyHarmless May 11 '11 at 18:49
@Martin: No, you shouldn't create too many branches -- even juggling more than a few with a good VCS gets crazy very quickly. So one per industry seems fine, if they differ significantly one from another in layout and content. The thing with branches is that branching itself is effortless, as is switching between branches. Merging after that which is the problem with SVN. A common use case is when making a change to the common underlying template and want to get that change across all (or a few) of your branches. – Martin Tapankov May 11 '11 at 18:59
good point - thank you, that makes it clearer to me! So for your template example, it might be a good idea to put the "formatting" commands which define the general appearance into an extra tex file which could be loaded by all the branches. – MostlyHarmless May 11 '11 at 19:38

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.