Subject: Re: VSS vs CVS
From: [email-masked] (Diophantus)
To: [email-masked]
Date: Tue, 07 Dec 1999 05:16:02 GMT
Newsgroups: gnu.cvs.help

On Mon, 6 Dec 1999 17:06:42 -0800, Rajani <[email-masked]> wrote:
>Where can I find a comparative study between CVS and VSS(Visual Source
>Safe)?

Such a thing might be quite useful. I don't know of any writeup, but I have
experience with both systems.

I can give you a few major points:

1. Branching

VSS doesn't support branching in the same way that CVS does.  When you branch a
file in VSS, you must create a clone of the file.  This means creating a new
directory (or "project", in VSS terms) where the file will reside. The new file
shares a history with old up until the branching point.  If you do a lot of
branching, your VSS tree becomes polluted with subdirectories.  I don't call
this branching at all. I call it code forking by way of making a *copy*.

This so-called branching breaks links; that is to say, if the file being was
linked under multiple projects, these links are preserved, but not inherited by
the branched version.

There is, however, a way to make a wholesale copy of a tree within VSS such
that *internal* links in the original tree are autoomatically reproduced in the
copy. External links are broken.

In CVS, branching is done very differently. Each file has its own version file
in the repository (a file with the ,v suffix). The version file contains all of
the revisions and branches. When you branch a file, the branching happens in
place.  You are not required to create another subdirectory in the respository.
Branching and linking are not related at all. CVS branching is truly powerful
because it doesn't upset your project structure and is done in place.  You can
switch your working copy to be on any branch.

The convenient "in line" branching of CVS makes it easy to use branches
casually. Unlike VSS, you don't have to recreate a whole tree just to create a
branch of a project! In fact, branch creation does next to nothing in CVS; all
it does is create a branch tag in one or more source files.

2. Linking

VSS has a strange notion of file linking that resembles the UNIX hard link.  A
file can appear in more than one project.  When you branch files (which is done
by a process that is basically copying) information is retained about the
origin of the copy, which makes it possible to perform merges when changes are
done to the original, or to the copy (in either direction).  The strange part
about the links is that directories cannot be linked!  Thus it is not possible
to link one project as a subproject of more than one other project. You must
instead link the files individually.

CVS, on the other hand, runs on a UNIX workstation and the linking is done by
ordinary symbolic or hard links. Using symbolic links, you can easily make a
directory appear to be a subdirectory of another. Files can be shared similarly
among directories, using symbolic links.

3. Merging

CVS lets you merge (patch) arbitrary deltas onto your working copy.  Suppose
you have some working file foo.c.  You can select the difference between any
two repository versions of foo.c and patch those differences onto foo.c.   When
you are developing on multiple branches, you must manually keep track of the
branch revisions so that you merge the appropriate deltas and don't merge
anything twice or forget to merge anything. This is done by carefully tagging
the releases of your work.

VSS has a merge feature to synchronize files that have been branched (cloned).
It automatically keeps track of what has been already merged, so you can bring
each independent version up to date with all the others.  This is not as
flexible as the CVS "merge any delta" feature, but it is somewhat more
foolproof, particularly for inexperienced users.

4. Concurrent Work

Concurrent work can be configured in VSS. By default, strict locking is used.
Only one developer can work on a file at a time. However, "multiple checkouts"
can be enabled, for more CVS-like operation. The multiple checkouts can be
enabled globally or from each client's perspective. The method is somewhat odd
because the discipline still resembles strict locking. That is to say, you are
still required to go through the same steps of locking a file (called checking
out in VSS terminology). It's just that multiple locks are allowed from
multiple developers. 

In CVS, there is no locking by default, though it can be arranged. There is no
explicit action to be taken when you want to work on a file. Just work on it
and commit the changes. There are ways to indicate that you are editing a file,
and it is possible to register oneself as a watcher to observe the changes of
status that a file undergoes. But there is no requirement to use this.

5. User interface

VSS has an integrated user interface and a management interface. Everything can
be done through the UI, and you can view the entire repository in it.  There
is also integration in the from of some Microsoft version control API that I
know little about; it allows tools written to the API to use VSS, or any other
version control system which conforms to the API.  (I'm less than impressed
with the integration between VSS and DevStudio, which is presumably provided by
this API. You will find that many developers perform to do their VSS checkouts
and checkins in the standalone client rather than via the integrated
interface).

CVS has a standard command-line interface. Some things cannot be easily done
through this interface, such as managing symbolic links in the repository.
There is no mechanism to browse the repository. If you have a locally mounted
repository, you can view it using conventional filesystem tools. But the remote
access methods to CVS don't let you browse. However, because of the way CVS
works, there is less of a need to browse. You just have to know the name of the
module to check out. Once you have a local working copy, you can browse that.
Hence the few GUI tools that exist for CVS, like WinCVS for Windows, are
centered on the working copy.  Under CVS, many cycles of the same project can
live under the same module in the same directory tree, thanks to in-place
branching.  As mentioned before, VSS branching requires the proliferation of
copies of files, because its branching feature depends on it. Therefore the
ability to browse the repository is necessary to the VSS user.

6. Openness

VSS loses big in this area. It is a proprietary system developed by Microsoft
and Mainsoft. The source code is not open and it is subject to strict licensing
agreements.

CVS is free software: it is freely distributed in source code form.  Because it
is open, mature and supports distributed development over the internet quite
well it is favored by a lot of free software hackers. The various BSD UNIXes,
the GNU C compiler, Mozilla, The GNU Image Manipulation Program (GIMP) are just
some of the projects which use CVS for concurrent development and managing
releases. Of course, CVS itself is versioned using CVS.

7. Security

VSS uses some proprietary client/server protocol, possibly based on Microsoft
RPC.  I don't know how secure that is. CVS can use a number of different access
methods to remote repositories. There is an insecure protocol called pserver.
It can work over rsh (remote shell) which is insecure, and also over ssh which
is very secure. There is also support for Kerberos via the GSSAPI that can be
compiled in.

8. Working Copies

CVS and VSS difer markedly in their relationship between the repository and the
working copy. VSS essentially acts as a database that has little relationship
to working copies.  The standard GUI browser is a window into the repository.
All state information regarding locks (checkouts) or version pinning is
centrally maintained. For any given folder within VSS, the user can designate a
target directory on a local drive where the files in that folder will go when
taken from VSS. A given folder in CVS corresponds to just one designated local
directory (at a time).

CVS, on the other hand, has an entire different discipline. Under CVS, the
working copy of a module is endowed with meta-information which points back to
the repository.  State information specific to a working set is maintained
within that set and not in the repository. One of the nicest features of CVS is
that one can have multiple independent working copies of the module;
essentially one can pretend to be two or more developers!  You can do different
development in each copy, and then merge it all together by commiting the
changes. Of course, each copy can be independently set to a different branch
too, which is especially useful.  Each working set remembers which repository
it came from, too. So if you participate in projects on various CVS
repositories around the net, it's quite easy. The CVS repository you
communicate with automatically depends on what program you are working on.

9. Pins and Stickies

CVS has a "sticky" features: sticky tags, sticky options and sticky dates.
These sticky things are properties of the working copy.  Sticky tags can force
a working copy to be on a particular branch. They can also pin the working copy
to a particular old revision so that you can't accidentally commit changes.

VSS doesn't have sticky tags. How it resolves the branch ambiguity is by
turning branching into a copy operation, as mentioned before. You know what
branch a working copy corresponds to because it came from the VSS folder
containing that branch, and only that branch. 

On the other hand, VSS has a feature called "pinning".  It's possible for a
user to pin files to a certain version. This means that if someone tries to get
the latest version of these files, they get the pinned revisions rather than
the latest. Pins also prevent checkins from happening to these files in the
particular working directory.  Pins are a property of the repository, so are
seen by all participating users. However, pins are also a property of
individual file links.  This is what makes them useful: you can link a file
from someone else's project into your own project. THen in your project, you
pin it at some certain desired release. As a result, you will not pick up
changes made to that file in the original project or any other project where it
is linked. By the same token, in your project, nobody can commit a new revision
to the file either.

(In some ways, pinning is a solution to problems caused by sharing of files,
rather than sharing at the component level. It can be effectively emulated by
CVS sticky tags; there is little trouble in arranging for your software team to
use only known stable releases of some component produced by another team.)

10. Multiple commits

In CVS, you can perform operations on many files spanning multiple directories.
For example, you can do edits in many places of a large directory tree, then
commit them in one operation.  To my knowledge, this is not possible in VSS.
The user interface allows you to select files only in one directory. You
can commit multiple files, but not in multiple directories.