Theory uses LaTeX almost exclusively.
I should hope so.
On revision control: what I want is a system that lets me say, "What did this file look like two weeks ago on Thursday?" but whenever I look into it that doesn't seem to be what they do. (There's some large chain of diffs or something.) Am I missing something? What revision control system should I be looking at?
Okay, version control 101.
The idea of version control is that you have a long series of commits, or diffs. You can think of each commit as an operation which was applied to the previous version to get the next version. So for example, your commit could be "Add the line 'hello' to the end of file 'foobar'". More commonly, people think of a commit as a marker that says "I want to save my work up to this point", I'll explain why in a bit.
Once you have a series of commits, you can use software on top of it to get the system you want. The most common one nowadays is git, but that's not too important for the main idea.
Let's say you want to see the file from last week. Then, you can say, "From the current version, rewind the commits I made until I get to this version from last week". Since you have a record of every change you made, all you need to do is apply the operations from each commit in reverse. Note that you don't actually delete the commits you've made from the record. What you've done is traveled back along what's called the source tree. Whenever you want to go back to the most recent version, you can travel up the source tree to the last commit you made earlier, reapplying the commits you've made, and at the end it'll bring you to the version of the file you just left. This is why commits can be thought of as saving your work - whenever you make a new commit, you implicitly create a marker that lets you return to how the file looks right now, because once you've described exactly how you got here, anything can follow the steps you made and get the same result.
Essentially, version control stores a list/tree of operations to apply to files, rather than exact copies of the file at every point in time you want a backup. Whenever you want to see a version of the file, it applies/reverses those operations on the fly to generate the version of the file you want. The upside of this is that doing these operations isn't very costly in terms of time, and many commits are small and easy to store because you only need to record the difference between the two versions of the file, rather than the entire file itself. This makes it very easy to have thousands of files versions available at a moment's notice, while spending a relatively small amount of space.
Most version control systems aren't that user friendly, but I'm pretty sure there are GUIs for git that can make things easier.
