For those interested.... the messages are a little old now, but most still apply.... -- Vi de udřdelige inviterer dere til ĺ slĺ dere sammen med oss
Here you go. I should add that it looks like database inconsistency problems are gone in VSS 6.0. Unfortunately, UNIX support for VSS client is gone in version 6 as well. Eugene. -----Original Message----- From: Mark Derricutt [mailto:[EMAIL PROTECTED]] Sent: Saturday, September 09, 2000 2:55 PM To: Eugene Kramer Subject: RE: CVS vs Visual Source Safe... I'm not sure if Pine will handle all the exchange/outlook attachments (should do), but if you email them to [EMAIL PROTECTED] that would be great (thats my current work email, using outlook/exchange). Mark
On Thu, 30 Dec 1999 16:23:03 CST, Win32 M$ <[EMAIL PROTECTED]> wrote: >Hi Jacob, > >>This is not to start a flamewar between MS and OSS. > >No flamewar, the comparison is between the two tools ;-) > >Now, where were we: > >CVS do has some advantages in compare to VSS like: >1. Works better in the WAN (Internet etc.) environment, when the team is >working from home >or is geographically separated for some reason. >2. It allows you to work better in a kind of sandbox, you can easily 'take a >job home'. >3. Using RCS format for repository - you don't loose repo if you change your >mind. >4. The price - this one does not apply if you buy VC Enterprise, because >it's there already. >5. Allows the development on the different platforms, althought not without >little trouble. You forgot: 6. The *in place* branching and merging in CVS blows away VSS, where you have to link your files to a new project, and ``branch after merge''. VSS is a disaster when it comes to managing multiple streams of development. In CVS, branching is done in place, not by creating new directories in the repository. Developers can do branching quite cheaply for small changes. 7. Atomic commits across multiple directories. How do you select files in multiple projects for a checkin in the VSS browser? 8. Multiple working directores, possibly on different branches. In VSS you must explicitly switch working folders. In CVS, I can checkout a module to as many working directories I want, and make independent changes in each of these as if I were multiple developers. The working directories point backward to the repository, rather than the other way around. 9. Expansion of a $Name$ keyword to identify exported releases. 10. Branch tags in addition to revision tags. 11. Symbolic links to directories within repository. CVS is in a whole other league compared to VSS. >But... VSS has it's advantages as well. If you are stick to the Windows >environment it migh >be a small shock when you go on with CVS, but if are good on UNIX, or have >some people >at hand, then there is no problem. > >VSS integrates smoothly with VC IDE (you mentioned it). CVS doesn't yet. The That is a lie. VSS does not interoperate smoothly with Developer Studio. Many developers I know stick to the stand alone browser interface. I rather like how CVS integrates into a *shell* environment. The cvs commands are just ``aware'' of what repository you are communicating with based on where you are in the filesystem.
Found this <uaiY2.431$jw4.33162@burlma1-snr2> in comp.software.config-mgmt: == BEGIN forwarded message == Hi Folks, I have a grave warning for those of you using VSS 6 or thinking of using VSS 6. I'm told the problem does not exist in VSS 5 so you may want to reconsider upgrading unless Microsoft decides to fix this (they better). A summary of the problem is that you cannot reliably branch off of a label. If you create 3 projects a, b, and c: a / \ b c Label this "MyFooBar" / \ foo bar and 2 files under b and c, foo and bar. Then recursively label a "MyFooBar". Delete (NOT permanently) project c, so the project a now looks like this: a / b / foo If you do a show history on project a, it will show you all of the labels. Select the "MyFooBar" label. Push the Share button. This is the VSS way to branch off a label. Check the | | Branch after Share check box and pick a project to share to. Another Dialog Box comes up, check the | | Recursive check box. Click OK. A warning box comes up saying "File or Project Not Found". Click OK another Dialog Box pops up saying "You do not have access rights to $a/c". Click OK. You will see that your branch now looks like this. ProjectBranch / a / b / foo When it should look like this: ProjectBranch | a / \ b c / \ foo bar Any release engineer would tell you this renders Source Safe as a waste of space on the hard drive. In fact, it's downright dangerous, as we have seen. Chris Geggis == END forwarded message ==
Found this <[EMAIL PROTECTED]> in comp.sys.mac.programmer.codewarrior: == BEGIN forwarded message == In article <[EMAIL PROTECTED]>, David Sommer <[EMAIL PROTECTED]> wrote: >Is that True? No The rumor was in regards to future versions of VSS and our statement is ... To our knowledge, the new versions of VSS on Windows will be very Windows-centric and it's highly unlikely that we will be porting these to MacOS. Ron -- Metrowerks gears up for WWDC http://macweek.zdnet.com/ METROWERKS Ron Liechty "Software at Work" [EMAIL PROTECTED] == END forwarded message ==
> Besides, it's a hell of a lot more interesting to work with Linux, > instead of constantly wondering why such and such black box refuses to > work as advertised I think you may have answered your CVS question there (for you - others have others goals/priorities/&c). > So far, I'm told CVS doesn't handle branching/merging as easily as > Perforce, and changes are not atomic, which is not good as we'll have > a depot in Paris, and developers working off it from different places > in the world. The atomicity thing almost never comes up in everyday use of CVS. In fact, I've don't recall ever hearing anyone complain about it based on using CVS, as opposed to just thinking about it. And even if the situation did come up, the consequences would be mild. The branching and merging thing is more of an issue. CVS is better than some systems (or so I hear), but there is room for improvement with respect to things like remembering which changes have been merged from a branch (#39 in the CVS TODO).
On Thu, 4 Mar 1999 13:00:44 -0600, "Erik Funkenbusch" <[EMAIL PROTECTED]> wrote: >SourceSafe is "unreliable" mainly because of network issues. If you remove >those issues SourceSafe becomes extremly reliable. The primary reasons that >SourceSafe databased become corrupt is a) Network glitches (especially if >dialups are used). b) Power or disk glitches. c) file sharing glitches. (snip) >So, SourceOffsite not only solves the problem of slow WAN/Modem links, but >also makes the entire process more reliable. I know all that, and that's why we went back to SS after StarTeam 2. >The only valid point of your argument is that you want to use Unix as a >server. (Of course doing this introduces the problems of CR/LF conversion >and other issues). Corrupted DB, un-usable through a modem or WAN, and running only under NT are good enough reasons to look elsewhere, IMHO. >Don't get me wrong, I don't thing VSS is a great solution for everyone, but >it does do certain things that no other source control product does, and it >*IS* the easiest of the bunch to use and administer. All I'm saying is that >you should make your decisions based on real problems, and not imaginary >ones. SourceOffSite is release 1.0... Adding one more unreliable piece of SW on top of a not-so-reliable piece of SW, on top of a not reliable OS is not my idea of productivity. The same reason we will not switch from Linux sendmail to Exchange as the powers-that-be would like us to. My job as an admin is not to do beta testing for free for MS and others. Besides, it's a hell of a lot more interesting to work with Linux, instead of constantly wondering why such and such black box refuses to work as advertised, better for my blood pressure, and a better investment for my longer-term professional plans, me thinks. Hence my post: Why shouldn't we go CVS instead of commercial products? So far, I'm told CVS doesn't handle branching/merging as easily as Perforce, and changes are not atomic, which is not good as we'll have a depot in Paris, and developers working off it from different places in the world. Thanks for your comments though, FF. -- The system required Windows 95 or better, so I installed Linux!
Frédéric Faure <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]... > On Wed, 3 Mar 1999 16:31:03 -0600, "Erik Funkenbusch" <[EMAIL PROTECTED]> > wrote: > >There is a 3rd party prodcut called SourceOffsite which alleviates the > >WAN/Modem problem. It's relatively cheap too. > > Yes, I know that product, but SS is already unreliable enough. Adding > one more layer is out of the question. Besides, we'd rather run the > server on a Linux/Unix system instead. SourceSafe is "unreliable" mainly because of network issues. If you remove those issues SourceSafe becomes extremly reliable. The primary reasons that SourceSafe databased become corrupt is a) Network glitches (especially if dialups are used). b) Power or disk glitches. c) file sharing glitches. Since SourceSafe manipulates the files directly over the network, any glitch in the network structure can potentially cause a file corruption. The same is true if power is lost or the disk drive hiccups (or crashes). Also, because the same file is being accessed by more than one program at a time, certain locking glitches may occur (this is a definate problem with VSS, but very rare). If you instead access the database through a single client/server access point that runs on the same machine as the database, then you've removed many of these problems. (Power and disk problems can still result). So, SourceOffsite not only solves the problem of slow WAN/Modem links, but also makes the entire process more reliable. The only valid point of your argument is that you want to use Unix as a server. (Of course doing this introduces the problems of CR/LF conversion and other issues). Don't get me wrong, I don't thing VSS is a great solution for everyone, but it does do certain things that no other source control product does, and it *IS* the easiest of the bunch to use and administer. All I'm saying is that you should make your decisions based on real problems, and not imaginary ones.
Mike Baker <[EMAIL PROTECTED]> wrote in message news:3t+$5RAOZQ32EAN$@tascomp.demon.co.uk... > I can't believe CVS can be worse at branching than VSS. This is one of > the things that is prompting me to look at CVS as an alternative to to > VSS, which we have used for about 3 years, and driving me up the wall. CVS has much better branching than VSS. VSS on the other hand has certain advantages with it's project orientation and sharable projects that CVS can't provide (such as the ability to have the same project be part of two different source trees at different revision levels).
Message http://www.egroups.com/list/info-cvs/?start=6780 > > >>>>> "Erik" == Erik Sette <[EMAIL PROTECTED]> writes: > > Erik> Hi all, Has anyone here tried Source Safe for NT? > > We have used SourceSafe and CVS extensively on a project which I have lead > during the past year, and IMO, CVS is by far a more usable product. Our > setup is both repositories reside on a Linux box (P150, 64Mb RAM). We use > CVS in `pserver' mode. > > My number one complaint is with regard to speed. A few of our developers, > myself included, work from home over dialup (ISDN and 33.6) connections, and > in the office connected to a real LAN. VSS is rediculously slow over a > dialup connection at even the most mundane of tasks such as viewing the > repository, much less actually checking something in or out. > > In my estimation, there to be no difference in speed between the GUI and the > command line interfaces either - it appears to be the underlying protocol > which is at fault. This is no great surprise since there is no server, per > se, and no real protocol either with VSS. All VSS code runs on your > workstation and accesses the various files over the network. > > CVS is much better, even without using compression. > > Cost is another factor. VSS at $500/seat seems way too pricy for a > glorified SCCS. I suppose the cost might well be justified since VSS is > integrated with other Microsoft products, including VB and VC++. Some of > the developers on the project liked this, however, some of them found it > annoying and didn't use it. > > Another problem for us was one of having to support multiple platforms > including NT, SunOS, Linux, and VMS. VSS can't do that. > > Erik> Can it do everything that CVS can do? > > It depends on what you mean by everything. The answer to this question is > likely no but who actually uses _everything_ in CVS anyway? The thing to > look at when answering this question is the developer paradigm you wish to > enforce: CVS supports concurrrent development while VSS does not. > -- > --------------------------------------------------------------------------- > John D. Amidon, TransCore, 3500 Parkway Lane, Suite 600, Norcross, GA 30092 > e-mail: [EMAIL PROTECTED] | V:+1 770 447 6831 | D:+1 770 449 7268 > --------------------------------------------------------------------------- > > > ----- See the original message at http://www.egroups.com/list/info-cvs/?start=6780
Scrive Jo Hagelberg ([EMAIL PROTECTED]): >My personal opinion is that StarTeam would meet our needs very closely. I >just have to convince the MS biased people and disperse any fear about >Starbase's future. Further it would be fine to have a *reproducable* bug in >VSS that I could demonstrate to my people to make the decision more >waterproof (ah well, Windows *never* is reproducable, however, if there's >sth please give me some details). Actually, while we're using SourceSafe a lot in our shop, I can't recall any outright *bugs*. However, I think there are some serious limitations. Here is a scenario that you could use to see whether the version management system you are considering is worthwhile or not. Say that you have set a label (created a class or whatever the terminology of your VCS is) that defines a version that you release to the market, to test or whatever. Now, there are four things you may need to do with this version: 1. Fix a bug in a file, and add the new revision of the label. 2. Rollback a file to a previous version, because some developper had checked in something which was not to be in this version (and is not compatible with the new version.) 3. Add a new file to the label (because someone forgot to check it in, or because it was needed to fix a bug). 4. Remove a file that shouldn't be there. The VSS5 GUI can do none of those. The VSS6 GUI can do 1 and 2, if it has a VSS6 database. It still can't do 3 and 4. If you use the OLE interface you can do 1 and 2 quite easily, with both VSS5 and VSS6. I think I know how I can do 3 with the OLE inteface (but performance may not be the best). 4 appears to be difficult to carry out without tricks. It should be added that, if you need to put an old version of the file, into more than one label, you run into problems with VSS, unless you can accept to check in the old version as current. (A really awful kludge.) -- Erland Sommarskog, Stockholm, [EMAIL PROTECTED] This could have been my two cents worth, but alas the Swedish government has decided that I am not to have any cents.
On 06-Dec-99, 23:16 (CST), Diophantus <[EMAIL PROTECTED]> wrote: > 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. This isn't quite true -- if you use one of the "search" functions (such as by name, or by status (e.g. all modified files in tree)), then the list (may) contain files from several subdirectories, which you can select and commit as one operation. Steve -- Steve Greenland | /"\ ASCII ribbon campaign Ellipsys, Inc. | \ / against HTML email [EMAIL PROTECTED] | X http://www.ellipsys.com | / \ The 'M' is *not* for 'mail'
Great summary of many significant differences. Couple of clarifications below... On Tue, Dec 07, 1999 at 05:16:02AM +0000, Diophantus wrote: > > 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. Agree with the strangeness of VSS in all dimensions, but the latest VSS will allowing 'sharing' directories. One repository I've worked on, for example, had a 'common' project with subprojects (directories) such as lib, include, etc. The subprojects of 'common' were shared into at least a half-dozen other projects (i.e. include, lib, etc. were linked as subdirectories under many projects). > 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. Actually, you cannot do some things through the VSS GUI. You must revert to the command line client. A great (and critically important) example of this is so-called back-branching (i.e. creating a branch based on a pre-existing label/tag that isn't the latest revision in the repository). This can only be done through the command line client and is a pain. Thanks again for a great summary. -scott
On Mon, 6 Dec 1999 17:06:42 -0800, Rajani <[EMAIL PROTECTED]> 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.
