Slashdot Mirror
Moving from Source Safe to CVS?
"Many projects have been suffering problems with SourceSafe. I believe this owes to its leaving management of the source database to the client program instead of the server. A client machine locking up or losing net access in the middle of a check-in can do serious damage. Further, the results of slightly different versions and third-party access utilities with imperfect implementations should be pretty obvious.
For programmers, the two IDEs we use are Visual Studio and CodeWarrior. Both the Linux and Windows versions of CodeWarrior have CVS built in. I can find a few Visual Studio CVS plugins, but no rave reviews of any of them.
For artists and managers, I'm not sure where to look. They definitely need a Windows GUI tool; again, I've found a few options, but none seem quite so easy as SourceSafe. I also worry about whether CVS the right tool for large binaries. As a game company, we deal with 3DS Max files, bitmaps, Word documents and a fair number of compiled executables. Will CVS effectively store these based on differences, or will the database bloat?"
2 years ago, I set up a sourcesafe for use with the C++ development in our company (3 coders).
It was fine until the day a network adapter in one of the developers' PCs had some problems. After some error messages while checking in some work, it resulted in a completely corrupt sourcesafe database. It was unusable and we had to restore it from backup.
That's the problem with SourceSafe, it's not a true client/server system but rather each client can access the shared SS files and make modifications in them. This lack of security checking on the server is bound to cause problems especially if the number of people accessing the SS increase.
True warriors use the Klingon Google
One nice CVS frontend is SmartCVS (www.smartcvs.com). It's written in Java, so it's cross platform (I tried it under Windows, Solaris and Linux). It aims to replace VSS's explorer. You can get a feature-restricted version for free or pay something like $35 for the full version.
One thing that you should promote about the move is the number of tools that are available for CVS. For instance, there's CVSWeb. It's a web frontend. There's CVS Search which lets you search through comments, etc. A search of freshmeat comes up with a lot of choices.
Finally, remember that there are scripts to help migrate from VSS to CVS. vss-to-cvs
-Dave
Citizens Against Plate Tectonics
I have used Jalindi Igloo successfully, and its an excellent piece of work. It makes access to the repository transparent, as does VSS integration into VS.
While I like CVS, and attempted at one point to get my company to move to it, I have to admit that there are a lot of features in VSS that make it more powerful than CVS. This includes "little things" like versioning of directories (so when you check out a label you get exactly the right files (and file versions) and directories. File sharing is also incredibly useful (we have several projects that have to share header and/or source files, in a case where libraries aren't an option).
Before you rush to move off VSS, consider your situation carefully. If you have a large history of development in your repository (as we did), then you are going to lose all of that in moving to CVS!! There is no tool which can take all your revision history with you.
CVS has been network access (for non-local networks) than VSS, but poorer tools; and in the case of VC the integration is not as good. VSS is a more stable product than many people give it credit for; but yes, databases do become corrupt (I've seen this with CVS too, when the server went down unexpectedly). Backup is always your best line of defense against corruption.
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
About a year ago the company where I work moved from Sourcesafe to CVS. The main reason was a series of corrupted databases that dragged work to a halt for hours.
For the coder CVS is fantastic. CVSWeb, bonsai, and (my favorite) LXR make viewing code, managing checkins, and searching code easy. If you have a mixed linux/windows shop both groups can use the same tool.
For the non coders it's not as nice. The windows interfaces are decent (especially TortoiseCVS) and let people work fairly well.
However it all breaks down in binaries. CVS Can't diff binaries, cvs tools can't preview them, and all in all they aren't handled cleanly. People will check the same file in twice, overwrite changes, things like that. You can recover without too much hassle (If you're familiar with CVS, but the first few times will be ugly)
Even with the large amount of binaries you had I would still say switch, the auditing tools for CVS make it worth it (The stability isn't bad either). But you will not solve any problems with binary files.
CVS does take some retraining, instead of locking files you have to get used to people merging before they check in. Those problems disapear fairly quickly, but there will be a bump of a few weeks while people get used to that.
I once had a contract were I was hired at the same time as a bunch of other progammers to release a 2.0 version of a product. We were reorganizing the project and setting everything up again from scratch and decided to use CVS. It was an easy call since most of us new guys were comfortable with CVS having used it in other projects. It's light, it's fast, it's tested, it's multi-platform and it works.
However the original developers had used a combination of SourceSafe and some other proprietary versioning system for windows and they bitched and moaned about CVS like crazy. One of the only clients at the time was WinCVS, which is a horrible and not very intuitive client and they really balked. They felt like it was a step backward.
It was only after we had set up CVSWeb and cool build scripts that ran every night and sent out emails to the people who broke the build and other really helpful and productive functionality that they finally came around. The fact that CVS is open and has been around so long and has quite a following really does make a difference.
Anyways, this was a few years ago and I'm not sure what GUIs there are now (I still use the command line) but if you do go the CVS route (which I think is the best idea for any size company) prepare yourself for the backlash...
-Russ
Me
You might like to take a look at using xdelta for your binary files. Who knows, maybe Midway can sponsor the integration of xdelta with CVS?
In my experience there are two major areas in which you should expect problems with a VSS to CVS migration. First and foremost, expect to have problems as the team adjusts to the non-exclusive model of file checkout. Force them to internalize the mantra: UPDATE FIRST, THEN COMMIT. The second area in which to expect adjustment pains will be the lack of a good GUI tool. This will be most problematic for the non-techie types, but even the developers will need some adjustment. Let's face it: you can't get a much simpler client than VSS, and that is it's (perhaps only) strong suit. CVS is kind of stupid about handling binary files as well, but this is less of an issue.
On a final note, a previous poster recommended PVCS. Believe none of this. PVCS is complete trash; the client is slow, buggy and unstable.