From: diophantus@nospam.org (Diophantus) Newsgroups: gnu.cvs.help Subject: Re: VSS vs CVS References: <024b01bf404f$55763ef0$3058a8c0@willow.brightinfo.com> Organization: Dotheads Anonymous Reply-To: diophantus@nospam.org Message-ID: User-Agent: slrn/0.9.5.7 (UNIX) Date: Tue, 07 Dec 1999 05:16:02 GMT NNTP-Posting-Host: 204.239.179.1 To: info-cvs@gnu.org Resent-From: info-cvs@gnu.org X-Mailing-List: archive/latest/11757 Lines: 200 On Mon, 6 Dec 1999 17:06:42 -0800, Rajani 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.