Vault vs. CVS

[jeremy_sg]

SourceGear Vault offers a number of advantages over CVS. At the most basic level, Vault was built to cater to Visual SourceSafe users who wanted to step up from VSS.

Vault was created to offer a seamless transition from VSS while still incorporating the very best features of CVS as well. Nothing typifies this more than the ability of each Vault client to run in checkout-edit-checkin mode (VSS style), or edit-merge-checkin mode (CVS style). This feature will be discussed in more detail later in this document, but for now it signifies how Vault contains features from the best of both the VSS and CVS worlds while keeping true to an easy transition for VSS users.

Vault offers atomic checkins.

An atomic transaction is a set of changes to a number of repository objects that is either fully successful (committed in full) or fully unsuccessful (no changes are made to any objects affected by the changes). The worst thing that can happen is that part of the transaction succeeds, while some other part fails, leaving the build in a broken state for everyone else.

With Vault, either all of the transaction succeeds, or none of it does. This allows you to always be confident that your checkins will not leave the tree in an odd state. Since Vault uses SQL as its backend storage device, transactional support comes in a well tested package. CVS cannot perform atomic transactions.


Vault has a more full featured GUI.
There are a number of unofficial CVS GUI interfaces available. However, they are all different, and each one provides some features while lacking others.

The Vault GUI was created to be so familiar to VSS users that they could start working immediately. Common features have the same names and even keyboard shortcuts as their VSS counterparts.

Moreover, the Vault GUI is structured with remote development in mind. For example, each file shows its status relative to the repository at any given time. The pending change set window automatically detects and presents to you a global view of what files have changed on your system.


Vault can perform complex queries.
Since Vault stores data in a relational database (SQL), Vault is able to perform historical queries using a variety of search criteria. When performing a history query, you can sort by operation, by users, by dates, by projects, by phrases in comments, or by any combination of such. This data can be sorted by any of these factors, and then exported as text or html.

One of the reasons for having a source code control system is so that you can quickly find historical information about previous checkins. The ability to perform intricate queries with multiple parameters makes this an order of magnitude easier. CVS cannot perform complex historical queries. </blockquote>

Vault versions renames and moves.
Vault is architected in such a way that when files are moved or renamed, you can still build the tree as it looked before the file was moved or renamed. In fact, you can fetch the Vault tree as it looked at any point in time, and all files and folders will have the old names and locations they did at that time. This is far superior to retrieving historical versions of files and folders and seeing them presented with their current names.

This difference is critical since build scripts at that previous time will be out of sync if these files appear as their recently moved or renamed states. CVS does not version moves or renames. </blockquote>

Vault can run in either edit-merge-checkin mode, or checkout-edit-checkin mode.
There are two very different and widely used methods of development.

One, employed by CVS, has the developer make edits to files in a local view. Then, when these changes are ready to be committed, the main server is contacted to determine if there are any merge conflicts. Once conflicts are resolved, the checkin occurs. This method is often called edit-merge-checkin.

Another widely used method, employed by VSS, is to have developers specifically check out what files they will work on. Once checked out, those files are locked from being edited by other users. Changes are made and then checked back in. This method is often called checkout-edit-checkin.

Vault lets each client user run in either of these modes. This means each person can choose the development strategy they prefer most.

Vault stores all files in delta format.
This means Vault stores only the changes from one revision to the next. Many development teams must store large binary files in their repository. Since Vault only stores revision to revision changes, repository sizes and download times for large binary files are significantly lower in Vault.

CVS does not store binary files in delta format.

Vault can use SSL for all client server communications .

Any remote team of developers must be concerned about moving source code files across the internet in unencrypted format. Vault uses SSL, a proven technology, as its encryption mechanism. Since IIS already has SSL built in, and since Vault uses IIS, there is no extra setup time.

CVS does not directly offer any encryption.

Vault contains sophisticated label, branch, and merge branches support. Vault is able to show labels as virtual branches, allowing easy manipulation of past labels. Moreover, Vault's merge branches wizard allows a step-by-step mechanism to merge branches. Vault supports the ability to merge a branch, make more changes to the branch, and merge again. This level of support for code branching make a tremendous difference for teams doing releases from different major code bases.

CVS does not offer the ability to perform repeated merge branches from the same label.
Vault contains pin and share features.
VSS has the concept of pin and share. Share allows files to be shared between projects, so that a change in one immediately causes the other file to be updated as well. Pin allows a file to be locked to a previous version. Vault extends the feature set of pin and share over VSS by allowing folders to be shared and pinned rather than just files. Folder share allows file additions, deletions and renames to occur in all share locations as well as checkins.

CVS does not support the concept of share or pin.