SVN stands for Subversion and is a version control system. It is primarily used to store current and previous versions of source code and it allows for concurrent editing of those source files by multiple people. In Mendix projects, custom Java code is stored in separate .java files that can be stored in SVN to keep track of different versions created over time. Common practice is to also include the .mpr (Modeler) file in SVN, even though this is a binary file which cannot be edited concurrently.

SVN is a centralized version control system, mainly used for managing source code, but also used for other text-based data that can be changed over time by different people.

People who work with source code on a daily basis rely on such systems and are familiar with their workings, but they can be bewildering for people who encounter them for the first time.

The easiest metaphor I've found for it is to view SVN as a library system. The difference with a traditional bricks and mortar library is that often the people who check out a document will alter it and send the changed version back to the library. That way, the next person who comes along and checks out the document(s) will always have the latest version. Also, anyone who checks out a document (or tree of documents) can view the history and see who made changes over time and what these changes were.

Generally speaking, SVN is primarily used for text-based structures such as source code. However, many projects use it to store and manage all objects associated with a project, regardless of their inherent suitability for storage in SVN, because it is convenient, provides a basic activity trail and allows activities such as backups of the project to be performed without re-inventing the wheel.

If you have access to a trusted version control store such as SVN, I would recommend using it for any project that requires collaboration or is used in production.