IonForge’s Evolution

IonForge’s Evolution is a version control system with some additional feature. For a single user, Evolution might be overkill; however, for a large-scale project, Evolution offers a variety of options and extended features that could (in theory) make a project leader’s life a bit easier.

Out of the box, Evolution offers the standard fare in version control: multiple user accounts, multiple user groups (for multiple system administrators), and file version control. But, it also offers various other features, such as the ability to diff productions and builds, to features such as “Work In Progress check-in,” which basically allows you to check in multiple versions of a file without commitment to the main tree. As with almost every version system around, Evolution allows you to check in other non-source files, such as marketing materials, bitmaps, and other files that must be checked before it is sent out for production.

Evolution breaks projects down into productions, which allows you to work at an overall component level instead of at the individual file level. This is both good and bad, as an expert in the system could easily increase their productivity; however, those used to other systems (such as CVS) will find the paradigm a bit awkward. Also, the “production ladders” is a system which allows you developer to track the stage of development a production is currently in. In a nutshell, the ladders system allows for an easy-to-do custom build, re-build an earlier version, and generate a status report on the current production. It’s a handy little paradigm when a new build breaks features of a pervious one.

Evolution also features real-time sync, with almost no additional overhead, since the server only updates the information in one place when the file changes. This allows Evolution to do some nice things, such as reflections.

“Reflections” is a system that allows for a newer version of a file to be worked on, while maintaining a copy of the original one. The feature works by creating a reflection of the original production… it’s kind of hard to explain, so I’ll let the user manual do the talking:

“Reflections solve the common problem of how to maintain a version of a product while working on a newer version. It keeps changes both isolated and synchronized in real time. If you reflect a Production into a new Production, any changes to the original will reflect into the new one until the link is broken by changes in the new Production. Only the changed links are broken; all the rest remain in place until they are changed. This means that the bug fixes in version 1.0 are automatically included in version 2.0, without the need for tedious, massive merges at the end of a production cycle.”

In other words, it helps make maintenance on a large-scale project much easier; however, it’s not an original feature, and has been standard fare (in various forms) in most version control systems.

Something we touched base on earlier was the “Work in Progress check-in” feature. This is something that I’ve not come across in other version control systems, so I apologize if the concept is really cool to me. The idea is that you can check in new files without contaminating the build process with unfinished/broken work. As a side-effect, this acts as a backup system for users who are afraid of losing their work, but don’t want it included in the final build. Also, since it does not contaminate the main tree, normal “get file” operations will get the last “known good” (non-WIP) version of the file. As the user manual states, source control only works if people use it, and you want to encourage the use of a version control system, and you don’t want work to be lost because people did not check in some files. So WIP encourages people to check in their files - finished or not.

Evolution only runs on Windows, and I was unable to find any information on a client for the Macintosh, Linux, or UNIX variants. So, if you’re going to use Evolution, you’re probably going to develop a Windows application, which is a big drawback for those companies who like to spend some time on cross-platform compatibility.

So, now that we’ve covered the basics of Evolution, let’s get right down to the bare bones: Evolution is not for everybody. While you can download a free “personal use” edition of Evolution, the system really shines in a development team.

In my original review of ionForge’s Evolution, I had recommended a multi-gigabyte machine for use as the main server; however, this was based upon a faulty machine. After speaking with the folks at ionForge, I ran the server on two additional machines, both of which were below the minimum recommended specs, and the systems performance blew me away.

After further testing, I was unable to push Evolution past 12 MB of memory use - and this was while I attempted to overload the server and see if I could reproduce my original results. After further testing, I feel it’s safe to say that the memory footprint of the Evolution server is miniscule.

The price of Evolution is $99 per user if you’re upgrading from Visual SourceSafe, otherwise it’s $550 per users. If you’re a small development team in possession of solid financial backing, or in a large corporation just starting your search for version control system, then Evolution deserves your attention, simply because it is robust enough to sustain multiple projects, while not costing nearly as much as some other popular systems. If you’re in the market for a VCS, consider Evolution as one of your many options.

This review has been revised. Some original statements about the memory use of the product have been revised, because of that, the overall opinion and recommendation has been changed.