[Tex/LaTex] How to deal with cls and sty files, relative paths and different platforms in a multi-user git repository

gitrevision control

To inlcude our self-written class we are currently using relative paths (\documentclass{../ourclass}), which triggers a warning (wrong class provided) and is rather ugly. The solution to this problem is discussed in these questions, for example:

But none of these questions discusses versioned multi-user/platform git repositories. The ideal situation would be that a new member or a member that got a new computer just checks out the repository and can build the documents as long as he has an up-to-date standard TeX distribution. So that the repository is fully self-containing and no tweaking of local PATH or texmf stuff is needed for each and every member/computer/operating system – all project-specific configuration should be defined within the git repository.

What are good approaches to such a situation? How to keep the user or per-computer configuration to a minimum and store all build configuration in a central repository?

Best Answer

I assume that you have one Git repository which contains your custom class, but that not every document generated with the class is to be included in the same (or any other) repository, but might exist just as a local copy.

(1) Submitting your class to CTAN

If the class source does not contain any sensitive information, you could upload your class to CTAN. After some time, it will be available in TeXLive/MikTeX distributions and every user that has an up-to-date TeXLive/MikTeX installation can use \documentclass{ourclass}. This is particularly useful if the class has reached a certain maturity and is expected to need only low maintenance.

(2) Cloning the Git repository multiple times

Usually, class files/folders do not exceed a few hundred kilobytes in size, already including vector image files, custom bibliography styles, etc. So every team member could, after creating a new project folder, call a git clone within the specific project folder. Via copies of local repositories and the --reference option of git clone, network usage could be optimised. Maybe you could supply scripts to your team members that automate and optimise intial cloning and subsequent pulling.

(3) Project folder structure

(1) and (2) would work without relative paths, which is what you requested. However, changing the folder structure on your team's computers might also be worth considering, e.g.

/home/.../git/                                (or C:\Users\...\git\)
             .../customclass/class.cls
             .../project-1
             .../project-2
                 ...

Then, keep the practise of \documentclass{../customclass/class}. This would require to ignore the warnings. If I may add a personal opinion: I did not fully understand why ignoring this specific warning should be problematic.