Using Tortoise SVN in a team setting with Unreal. I haven't used SVN for over a decade, only Perforce and Git. My understanding is that one of the pitfalls with SVN is that without careful communication it is very easy for users to 'clobber' each other's work since by default source repo files aren't locked when checking out to make changes.
Is there some way, via Tortoise or the cmd line to easily lock server files when checked out for modifications so they cannot be overwritten?
Your understanding is only partly correct. For anything that can be merged (i.e. textual data like source code), Subversion goes out of its way to prevent clobbering. For files that cannot be merged (i.e. binary files) you can force users to lock them before they work on them.
In general, Subversion will refuse to commit if there's a more recent revision of a modified file in the repository. In this case, Subversion requires you to
This is a simplified version of Subversion's basic work cycle, especially of the item Resolve any conflicts.
Let's see what this means for data that can be merged and for data that cannot be merged.
While it's not entirely impossible to clobber your teammates' work, you would need to actively discard or overwrite their changes. While mistakes do happen, Subversion is inherently not more error prone than Git or Perforce.
Locking all source code files by default would put an unnecessary restriction on the team.
With binaries (you mention Unreal so I guess you'll deal with image files and 3D models), there's the problem that they cannot be merged. If a conflict happens, you're left with a decision to use yours or theirs and nothing in between.
To be clear about it, this would still be a conscious decision a user has to make before committing the conflicting change. Even if such a collision happens, it cannot go unnoticed.
To prevent this case, you may choose to put the svn:needs-lock property on those files as explained in Force user to lock file in SVN before editing
In both cases, there's no guarantee somebody will not decide to be overly clever or just throw out a teammate's "inferior" work. The potential to disregard or misuse the system is there and no tool will be able to prevent it.
There's also a good explanation of locking models in the already cited Red Bean book.
If anything happens, you can always reverse-merge your changes to the last good state as explained in Undoing changes or right here on SO: SVN reverse merge?
The problem of concurrent editing of binary files is present in Git as well. IMHO, Subversion's centralized nature makes it far easier and safer to use than Git. On the other hand, Git being distributed is a primary reason for its ubiquity and success.
I possess only superfluous knowledge of Perforce so the following may be off. From what I recall, concurrent editing is not possible at all. Opening a file to write will lock it for all other members of the team. This behaves like Subversion with locking on by default.