Revision Management is expensive and difficult to implement

Training for Oculus' Revision Manager typically takes no more than an hour - most of the 'training' time is spent learning how to take advantage of the opportunities that revision management provides. The server portion of Oculus' Revision Manager installs in minutes and can be managed using a drag-and-drop web interface.

Revision Management is for large, distributed teams

A single engineer benefits from Revision Management just as much as a team of one hundred. For the single engineer, Revision Management provides a safety net for concurrently working on multiple projects. For the small, co-located team, Revision Management eliminates ambiguities about which simulation results are "the latest". Whether your team is 2 or 200, Revision Management facilitates collaboration.

Revision Management starts when the design is finished

Each day you invest time and money in pre-design, design reviews, and in design alternatives. This is a significant investment in intellectual property. Many organizations waste hundreds of man-hours reviewing the wrong documents, sending the wrong documents, backing out of incorrect design decisions, and searching for files, all before a design is 'finished'.

Revision Management does not produce better quality designs or save time

Without a revision management system, engineers typically waste at least 10% of their working day managing their environments and files. Another 10% is typically used trying find things, reworking, and reacquainting oneself after a weekend or vacation. This is time that could be spent pursuing additional solutions or innovating.

A sophisticated file naming system will get the job done

Naming conventions are not a revision management system. Using naming conventions such as "file name + person + date" adds yet another layer of complexity. Most naming conventions cannot be enforced and often fall into disuse.

The amount of time spent on "house keeping" and filing duties is continually increasing. Team members work on multiple projects, and a mix of file naming systems makes the switching between projects difficult and wastes valuable engineering and design time. Simple tasks become a search and rescue operation. Many team members simply give up and put it down to the archeological blues.

Revision Management will not ensure good names, but it will take care of the "who did what?" and "when did it happen?" housekeeping. And it does it automatically. It also provides the contexts for understanding how things have changed over the past day or year.

Email will get the job done

Email is not a revision management system. Although useful as a communication tool, email alone leads to confusion about versions of files/documents. Email does not keep track of different versions of files nor does it ensure that you are working on the latest documents, no matter how good your email's search capabilities.

Document Management is all I need

Document Management is a subset of Revision Management. Document Management systems are typically vaults - they focus on helping you to keep track of where things are located. Revision Management keeps track not only of where, but when. Many document management systems include mechanisms for keeping track of the revisions of individual documents. But they do not provide the interface or underlying structure to manage sets of documents as they apply to your evolving products.

PLM systems provide Revision Management for free

Most Product Life-Cycle Management (PLM) systems are tied to a CAD system. Many focus on assemblies and bills of materials; in these systems, the geometry drives everything. In fact, geometry is just another part of the product design. Does the PLM system encourage short, intense collaborative sessions, or is it a vault designed for finished designs? Does the PLM system encourage the proliferation of design alternatives, or does its interface inhibit you from exploration?

An effective Revision Management System not only keeps track of changes, but it does not get in the way of exploring and re-using those changes. It works with every type of data, at every stage of the product development process.

We can keep track of revisions without a complicated software system

Your job is complex. There are plenty of engineering, customer, vendor, and other issues to take care. Using Revision Management ensures that the focus of the team is engineering and design, not keeping track of file naming conventions. The result is innovation and quality.

Your Revision Management system should not be complex, but it should eliminate the complexities of managing changes.

CVS is good enough

Concurrent Versioning System (CVS) is better than no revision management, but Subversion is much better. Training is minimal: the workflow is the same, and most CVS operations have a direct equivalent in Subversion. Conversion is straightforward: a CVS repository can be converted to Subversion, with the complete history of every document intact. Subversion offers many benefits over CVS: atomic commits, easy branching and merging, better remote performance, better access control and auditing, ...

Command-line tools are all we need

You could pull your car over every 100 miles, stop the engine, lift the hood, dry off the dip stick, read the dip stick, check the radiator... But it is much easier to simply read the dashboard. When the indicators say the fluid levels are low, then you check and react. With instrumentation you can spend your time using the car to do things rather than spending time managing the car.

Command-line tools are useful for some people and some situations. But most people do not have time to (re)learn the commands each time they need to use them. Nor should they incur the frustration of errors caused by mistyping a single character. Your organization should maintain a suite of tools so that you use the right tool for the job.

Revision Management Systems and Performance Management Systems have to be separate

With Oculus' Revision Manager, each team member can see the performance metrics that are associated with each change to the repository. Changes to the performance metrics can happen automatically as part of the commit process, or manually as part of a review.

Imagine this scenario. Run a simulation, then run the tests/validation, with the last job scraping and summarizing the results. The results are stored in XML within the set of files that are committed to the repository. The XML is used in the project view to display all performance metrics. Team members may now see how well work is performing - is it degrading or improving over time? And of course it is plain to all where tests are not being run.