Comparison between CM+ and Vesta

Back to main page

SCM feature:	CM+	Vesta	Add to comparison: +CVS +AccuRev +Aegis +AllChange +Arch +Bazaar +BitKeeper +ClearCase +CMSynergy +Co-Op +Darcs +Git +LibreSource Synchronizer +Mercurial +Monotone +OpenCM +Perforce +PureCM +SourceAnywhere +Subversion +Superversion +Surround SCM +svk +Team Foundation Server +Visual SourceSafe
Atomic Commits	Yes. Commits are atomic.
Files and Directories Moves or Renames	Yes. Both moves and renames are supported, while maintaining history.	Yes. The unit of checkout/checkin is a directory tree. Files and directories can be added, deleted, and renamed between versions.
Intelligent Merging after Moves or Renames	Yes. Renames are Intelligent.	Unknown. FILL IN.
File and Directories Copies	Yes. An inexpensive operation that can be used for sharing files in multiple places. On deploy, you have the option of deploying only one of the shared files or all of them.	Yes. A new package/branch can be based on any existing version without affecting the past history. (This is also an O(1) operation.)
Remote Repository Replication	Yes. CM+MultiSite can be configured to clone a repository so that it continues to act as a single repository. Options include cloning only from the main site (i.e. not allowing updates from the clone) and restricting the set of files transferred to a cloned site.	Yes. Replication is a fundamental part of the design.
Propagating Changes to Parent Repositories	Yes. In CM+MultiSite, changes made at the slave are, by default, propagated to the Main(master) library, as well as to all other Clones (slaves). You may also propagate changes between unrelated repositories containing some of the same source.	Yes.
Repository Permissions	Yes. Permissions are defined by data, primarily, not by location. If location is a part of the data, it may be used to define permissions by location. Permissions may apply to a branch, file, problem report, test case, etc. Access may be extended based on peer group, manager, and access lists.	Yes. Access permissions for each package (the unit of checkout/checkin) can be different. Access permissions for a branch can be different from the basis package.
Changesets' Support	Yes. Change packages are known as updates. By default, an update is required to make any change. The update may be checked-in, differenced, promoted, retrieved, propagated, yanked (i.e. removed from history), etc. each in a single operation. Baseline alignment is performed based on the status (i.e. promotion level) of the update. Updates also record changes to directory structure: move, add, remove.	Not exactly. Vesta uses a related concept of configurations instead, which some has similar properties.
Tracking Line-wise File History	Yes. View revision tags.	No, but it would be easy to implement a tool that did this, as the Vesta repository provides direct filesystem access to all versions.
Ability to Work only on One Directory of the Repository	Yes. Any arbitrary set can be checked out and worked on. Similarly, arbitrary restrictions may be applied for check-in, including file ownership.	Yes and no. The unit of checkout/checkin (called a package) is a directory tree. Most projects use more than one. Once created, a package must be checked out/in as a unit.
Tracking Uncommited Changes	Yes. Use Updates | Delta | Delta Update. Or right click a file or directory and do a compare to workspace.	Yes. Intermediate immutable snapshots can be taken during an active checkout (with vadvance). These intermediate versions can be treated just like checked in versions: they can be replicated to other repositories and used as the basis for branches.
Per-File Commit Messages	Yes. Out of the box CM+ is configured to prompt for messages (i.e. comments) only per change. However, the schema is pre-configured so that you may prompt on a per file basis as well (typically done at checkout time as the entire change is normally checked in with a single operation.	Not exactly. The unit of checkin is a directory, and commit messages are assigned at that level, not to individual files. Since configurations are also versioned, they also have commit messages.
Documentation	Very good. There is a self-demo/tutorial to get you started quickly. Administration is minimal. So normal developer use requires only a 1 to 2 hour training session (or equivalent guide) to introduce you to concepts and capabilities (e.g. like updates, options). Customization documentation is also extensive but should normally be accompanied by a 2-day to 4-day course for GUI, Process, Data and Application set customization.	Quite thoroughly (HTML, man pages, published papers, a book-length research report).
Ease of Deployment	Yes. Typical installation need only be done on the server (with a single shortcut established on the client). This assumes file system connectivity. For IP only connectivity, installation is also required on remote clients. Installation is typically a couple of minutes. No dependencies unless web interface is used, in which case an Apache server is required. A download is available from Neuma's web site and takes you right into a self-guided fully working demo version.	Medium to Good. There is a detailed installation guide for setting it up using a binary kit. RPMs and Debian packages have been recently released. There are no dependencies on other software. There is a bootstrap package available to build Vesta from using "make".
Command Set	CM+ has several dozen commands that can be used both for operation and configuration of the product. As CM+ is change-based, commands are substantially different than CVS. The GUI is used primarily and implemented on top of the command set. As well, CM+ covers a full ALM suite and can be extended beyond, so there are many more generic commands for browsing, reporting, etc.	The command set is unrelated to CVS. Most of the time, users use about 5 commands. Few ever need to know more than about 20 commands.
Networking Support	Very good. File system connectivity, TCP/IP connectivity and Web connectivity may be intermixed. MultiSite connectivity is over TCP/IP, as is License server. Works well with SSH, NFS, SMB, etc.	Networking is inherent to the system. The repository exports both an NFS interface and an RPC interface. The checkout and checkin tools automatically contact a remote repository when required to perform an operation.
Portability	Good. Clients and Servers work on Unix, Linux, and Windows. MAC OS X port pending. Moving server from one platform to another is a copy operation only. Can have different platforms for different servers in a MultiSite configuration. Easily configurable Web client also supported. No CR/LF issues. Scripts are all portable as well.	Good. It should be portable to any UNIX system. Currently it runs on Digital/Compaq/HP Tru64 UNIX and Linux on several different CPU architectures. Ports to Solaris and FreeBSD are planned but haven't begun yet.
Web Interface	Yes. Can be configured to restrict which operations are allowed by which users, so that customers may access their requests without seeing development team data.	Yes: Vestaweb.
Availability of Graphical User-Interfaces.	Excellent. Windows and Unix/Linux GUI as well as web GUI. Extensively configurable via simple menu files, browser files, etc. Can customize the set of to-do lists by user/role, same for menus, pop-up menus, default visible tabbed reports, etc. GUI also used for all admin and for process and data schema customization. Also plug-in for Visual Studio, Eclipse, etc. and File Browser (Windows).	No GUIs are available, but the repository has a C++ API, and it is not hard to write one. (At least three different project-specific ones have been written by users at Compaq and Intel.)