Version Control System

VCS Main Screen

The Version Control System is a simple to use, single-user archiving program. When you have a file selected in Navigator, if you click the VCS button, the VCS program launches, open to the same file.

If the file has any archived versions, they appear in the Version Grid on the right. You can select one or a range of records in the Version Grid.

If you have an orange file icon selected in the tree view, the archived versions appear in the grid. You can Check In a new version, Check Out an archived version, Delete versions, or view\edit the selected version's Comment. A yellow file has no stored archives - you can only use Check In with these.

If you have a black, gray, blue, or green directory selected, you will see the most recent version of each checked-in file in the directory. In this view you can Check Out multiple files.

Preferences

The Preference dialog has only one setting - the VCS Base Directory. This is the directory under which VCS will store its archives. The default is the \proj directory. Let's say you have a project file called myproj.tbp. VCS will create a directory called \proj\myproj, and store all archives here. Individual files are stored at their full path, plus a directory with the same name as the file. Example: C:\mygame\mymod\maps\mymap.map would be archived at \proj\myproj\mygame\mymod\maps\mymap.map\.

All this path creation is done automatically for you - you never have to set up a VCS archive. It completely mimics your working directories under the VCS Base Directory. The original design philosophy for the VCS was to make you able to check-in a file in 3 mouse clicks or less. To achieve that, most functions that traditional versioning software makes the User perform had to be performed by the software. This works great for a single User product. You can even do parallel and multi-platform development, simply by using different VCS Base Directories.

It makes Team Development difficult, however. I have implemented a limited form of Team Development capability, able to handle possibly a half-dozen Users before its limitations become a problem. Here are the Rules:

1) ALL TEAM MEMBERS MUST USE THE SAME DIRECTORY STRUCTURES ON THEIR LOCAL DRIVES!!!! This isn't such a problem with Quake development, since your working files will be in mod directories anyway, and they HAVE to be the same.

2) ALL VCS BASE DIRECTORIES MUST BE ON A NETWORK-ACCESSABLE DRIVE. And users must have that drive mapped to a DOS drive letter - a raw network location won't work!

3) USERS MUST INDICATE THEY HAVE THE FILE CHECKED-OUT (LOCKED) BY EDITING THE COMMENT! This is the major pain part, because there's no way to globally edit the comments for multiple files.

Right now I'm designing the next-generation product. It will include a full-blown team development environment, plus stuff like automatic builds of a project using the latest versions, archiving in .zip files, etc. Until that's done, the current VCS should serve single Users well, and give teams with a low budget something workable.