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
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
Cervisia is a good QT based KDE frontend to CVS. We use it, and we like it. It is not as easy to use as the VSS GUI, but it will help migration from VSS to CVS a lot.
Regards
Maurizio
cvs pros:
- work concurrently unlike SS which is only
safe in single ( exclusive ) checkout mode
- merging is automagic when possible
and discourages developers from checking in
changes that haven't been tested with the
latest and greatest
cvs cons:
- sometimes exclusive checkout is desireable
( unmergeable binary files for example ) and
the support for this often missing or performed
at unpalatable granularity in CVS
- doesn't support "sharing" as in SS
( not needed in a "real" OS like Unix where
there are symlinks, but in redmond OSes...)
SS pros:
- familiar, easy to use GUI ( diffing and
history support bitchslap ANY known cvs client )
- better for storing binary data
SS cons:
- M$ nuff said...they didn't write SS, but
it runs on their decrapitated OS
- single, exclusive checkout implies much
attrib'ing and manual file merging during
real collaboration ( CVS' strongsuit... )
- random autonomous protein spills in the
VSS db causes frequent "everyone out of the pool"
drills ( where I work on the order of once
every couple of weeks! )
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.