Workflow for using SVN for many variations of some base documents (job applications)

Question

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. :-(

Answer 1

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.