I used to use SVN years ago. I recall there were a few minor annoyances, but by and large it was a good bit of kit, and TortoiseSVN was a good UI. In more recent years I've used Mercurial. Like Git it lets you have one (or many) local copies of everything on the server, which can be handy for speed or if you might have periods where you can't access the server. It also means that if the server catches fire, there's a fair chance people will have a copy of the source code somewhere. TortoiseHg has Mercurial covered. It's a good UI and like SVN, things work pretty smoothly most of the time. Fairly recently our team moved to Git. So far it seems very much that "Git" is rhyming slang. The Tortoise offering offers far less for Git. There are a lot of Git UIs out there, but it's tough to find a good one, especially if it needs to be free. Visual Studio does sort of okay on that front. As a result, I do a lot on the command line when using Git. Git's concept of branches, to me at least, seems far weaker than Mercurial's. It just seems to keep a record of the latest changeset for each branch and keeps a record of the parent changeset. Finding your branch's parent branch is at best tricky, at worst impossible. For me, Git has few if any advantages over Mercurial, and as a bonus has an unpleasant learning curve and unnecessary complexity. The whole world apparently disagrees with me, but I wouldn't recommend it to anyone as long as Mercurial is available. But if SVN is serving you, there's no shame in sticking with what you know, either. You could give Git or Mercurial a test drive on a personal/mini project if you want to see if the grass is truly greener (spoiler: with Git, it's less grass and more wasteland with bonus fly-tipping).

I'm currently doing this with a bunch of .iso files. The following seems to be a basicly competent application from what I can tell (it's what I've been using). I haven't watched a movie through yet, so I can't promise no audio sync drift, but what is nice about it is that you can select a zillion .iso files and leave it to go, rather than doing it one by one. And it seems to make good choices regarding aspect ratio etc. I've been using its MP4 option. Known downsides: help seems to be incomplete, no command line interface, uses original .iso disc names even if file has previously been renamed. Haven't tried to rip with a folder based source, I'm afraid. EaseFab Video Converter Ultimate: All-in-one Video, DVD and Blu-ray Solution for Windows (Windows 11/10 included) | OFFICIAL[^]

I view documentation as absolutely essential and just part of doing a good job. If class and function names are genuinely sufficient, then that's fine, but if you try and ask yourself all the questions that a new user of your code might ask, frequently there's plenty to document for clarity. I'm quite lucky in that I have a lousy memory, so when I return to my code later, I may not be that far from a new user of it myself! I find myself thankful to myself for getting the necessary details explained and documented clearly! I think if a user of your code has to read any of the code in your function bodies, your documentation is insufficient. I also think it's also valuable if you can to spend some time writing code that consumes your code - essentially walking in somebody elses shoes. It can show you how easy or otherwise it is to work with, and can reveal opportunities to improve the design, or perhaps suggest function overloads you can provide simpler versions of to reduce any pain. If there's anything cumbersome or unintuitive about your code, you'll hopefully encounter it and be able to rectify it.