Moving from Source Safe to CVS?

Snowfox asks: "At Midway Games, we're currently using Microsoft's SourceSafe. I'm evaluating other options, such as CVS. Currently, SourceSafe is used not only for source code, but art assets, project management documents and more. Has anyone made a move from SourceSafe to CVS? Can you comment on your experiences?"

"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?"

Comments

Source "Safe" ?

[codexus]

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.

WinCVS

[SsC]

We did this where I work. It's been great using CVS instead of SourceSafe, as CVS doesn't corrupt projects for no apparent reason. We're using WinCVS on the desktops. Sure, it doesn't have integration into the VS6 IDE, but we've made do pretty easily without it.

The other advantage of this was we got to build a nice linux box and put it in the 'officially supported' rack.. heh. :)

HTH.

TortoiseCVS

[XoXus]

For the managers, and others who need to use Windows, a better way than using WinCVS is TortoiseCVS, a shell extension that makes CVS repositories transparent.

http://www.wincvs.org/TortoiseCVS/index.shtml

CVS is your friend

[Anonymous Coward]

Never worked with SourceSafe, but CVS definitely saves the day were I work.
The most annoying problem actually ends up being Windows users ending up comitting a ^M in the end of half of the lines. :)

CVS has its quirks, but if you learn to handle it it does the job very well. In the future I would look out for SubVersion (subversion.tigris.org) though. It aims to improve quite a lot on CVS, so it will surely be marvelous.

Re:CVS is your friend

[coyote-san]

CVS has hooks that allow you to run external programs at various points. You can eliminate this problem by putting a call to dos2unix (or something similiar) at the appropriate place.

I've even been known to threaten calling a source code reformatter there, if certain individuals in the office continued to ignore the coding standards.

Using CVS w/ SCC Complient IDEs

[Halvard]

I haven't used this myself but surfing over to the WinCVS website, I found cvsscc. It's a project to map the scc stuff that MS uses to cvs. Another attempt, perhaps more mature, is Jalindi Igloo. The first paragraph from the website says:

"Jalindi Igloo is a program that allows you to connect Microsoft Visual Studio and other IDEs directly to a CVS repository. The program is completely free and can be used anyway you like."

These look to be just what you are looking for.

Re:Using CVS w/ SCC Complient IDEs

[Twylite]

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.

Re:Using CVS w/ SCC Complient IDEs

[DrZaius]

I've never seen a CVS repository get corrupted -- I've seen working copies get destroyed or problems with permissions.

The important thing to remember is that you can always fix CVS -- if you do get a corruption it most likely will only be in one file. You could probably open it with vi and fix it too (as long as it isn't zero length, which would happen if your drive ran out of space).

Of course, even a large CVS repository tars down pretty tightly, so you can keep lots of backups too.

SmartCVS and build tools

[drig]

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

PVCS

[truesaer]

I haven't seen anyone mention PVCS which is made by Merant. I used it this past summer on a project and it was great. It has a nice permissions system, and it has an interface in your web browser that looks like windows explorer. You can make complex folder systems, and it will mark things read only when you check them in, etc.

Ease of use was definitely the biggest reason I liked it. Check them out if you're shopping around.

Re:PVCS

[kableh]

As the systems administrator I get the pleasure of maintaining the PVCS server. All the developers do is bitch about how horrible a system it is. It is slow (server it is on is hideously over-spec'ed), almost unbearably so on Linux (although we think it might be related to NFS Maestro), and everyone who has worked with CVS seems to think it is much much better.

From what I have read it tends to be slow due to how it accesses the PVCS archives. It doesnt just check out the file and copy it to a work directory on your computer, rather it is constantly hitting the server. Here is a good document on PVCS' shortcomings (albeit with a slight bias, since it came from a competitors website): http://www.perforce.com/perforce/pvcs.html

There are some Perl scripts out there to transition PVCS to CVS, and I think I found links on the WinCVS homepage. I believe that is the direction we will be headed soon.

Also, PVCS is awfully pricey for what I consider to be a subpar product.

CVS vs SourceSafe

[schulzdogg]

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.

Re:CVS vs SourceSafe

[barzok]

SourceSafe can't diff binaries either; each revision is stored as a completely new file, rather than the difference between the 2 versions.

Re:CVS vs SourceSafe

[babbage]

Would it make sense then to have both CVS & VSS working in parallel, with CVS managing the textual stuff (code, text docs, etc -- any chance the word DOCs could be resaved as RTF? doubt it... :) and VSS doing the binaries?

My last job was a VSS shop, but I didn't deal with it very much. Everyone else was doing local machine development, while I was the web guy, so I could get away with not keeping all my code in VSS like the others. Still, I can see what people are saying about VSS being more peer-to-peer than client-server.

With that in mind, could CVS be set up to act as a peer to VSS, or VSS as a client to CVS? The latter makes a little more sense to me, but might not be implementable as long as VSS remains closed source. Getting CVS to feed binary data over to VSS might not be as clean a solution, but it seems like it should be doable.

That is, provided that you feel it makes sense to keep both systems running in parallel. I'm not familiar enough with their similarities & differences to say for sure...

many active developers using CVS

[DrewFish]

I've never used SourceSafe.

You didn't mention how many active developers are working on your project.

Where I work, we ran into trouble with CVS when we had 40+ active developers working in the same repository. If you have many different teams whose changes overlap on (even a few) common files, it can be difficult. In theory, branching helps with this, but in practice, branching just moved the conflict-resolution to a different step of the release process.

Hmmm... I guess a lot of our trouble was from how we organized our source tree and assigned projects. (Blame the managers! :)

For a while we had switched over to BitKeeper. It has it's limits, and we where definitely pushing them :) but it's a well thought out product. It did help manage the risks associated with code conflicts.

Re:many active developers using CVS

[cmowire]

Trust me....

SourceSafe will have problems before CVS will have problems.

So that shouldn't be too much of a concern.

Re: Jalindi Igloo

[Anonymous Coward]

I haven't had the best of experience with this plugin. I don't mean to put down its developers because I hear they made tremendous sacrifices to get their hands on the Source Safe/Visual Studio API, but Igloo wasn't particularly stable when we used it. This doesn't mean that our source code was in danger because (as previously discussed) CVS is less vulnerable to client problems than Source Safe; it just means that Visual Studio would hang from time to time.

Also, Igloo has a funny way of handling newlines that I never quite understood: it changes \n to \r\n but not the other way around or something like that. This causes CVS to assume that all lines have been changed when you start using Igloo. So you should first check out every file under Igloo, then check it back in with no changes; later changes will then be reflected normally.

Another thing you should be aware of is that Igloo allows multiple people to edit a file at the same time, whereas Source Safe does not. (This is not a bug, it's a feature. Seriously, it's just because Source Safe can't handle merges of multiple edits, whereas CVS can.) This can cause problems if people are used to using Source Safe and just assume that a file is locked when they check it out. Of particular importance is the newline problem that I previously mentioned, which causes CVS to assume that every line has been changed, because if two people modify the same file and then check it in, CVS won't know how to merge it, and we have lost changes because of this. (Of course, we only lost changes the first few times we used it, when the newline problem was still a problem.)

Bitching and Moaning

[rbeattie]

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

Re:Bitching and Moaning

[guusbosman]

The fact that CVS is open ... really does make a difference.

I totally agree on that -- in my opinion this is a very important advantage of using CVS. You will be able to control many aspects of the whole developing cycle.

It is for example pretty straight-forward to implement a lock/unlock policy (like SourceSafe does) using a few scripts on the server (they come with the cvs-distribution). Combined with, say WinCVS and a few client-side scripts, you will be able to get a pretty good imitation of the system SourceSafe uses. Might even help you with your binary files, as there won't be any merging anymore (although the database will get pretty big quickly).

Using CVS will give you a very good feeling: on the one hand the freedom to be able to rewrite parts of your clientside software if necessary, on the other hand a very big user-base who already did this, on the gripping hand you'll probably don't need this as the client are really getting better and better (http://www.cvsgui.org, http://www.cvsgui.org/TortoiseCVS/index.html).

Binary diff

[cowbutt]

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?

Proper links

[dlek]

Just to help out the lazy among us, here are those links again:

• CVSWeb
• Bonsai
• LXR
• TortoiseCVS

Subversion is getting close

[Anonymous Coward]

Check out Subversion (http://subversion.tigris.org). It is still in pre-alpha but it will fix a *lot* of the problems CVS has had. Some people are already starting to use it with the just the (buggy) features is already has. Should be BETA within a month or so. It can version directories and symlinks as well as regular files and it fixes the problems CVS has with binaries. It is already ported to Unix (Linux, *BSD, etc.) and Windoze.

SourceForge?

[fidget42]

Considering that this is being posted on /., I am supprised that no one is recommending SourceForge. Just me US$0.02

Try Cervisia

[Anonymous Coward]

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

OT: How about Excel?

[jmichaelg]

Is there some sort of hook for cvs to parse the code diffs in Excel? Excel Basic is embedded in the spreadsheet in some non-textual format and it isn't clear to me how it can be handled by cvs.

Re: Jalindi Igloo

[Snowfox]

Another thing you should be aware of is that Igloo allows multiple people to edit a file at the same time, whereas Source Safe does not. (This is not a bug, it's a feature. Seriously, it's just because Source Safe can't handle merges of multiple edits, whereas CVS can.) This can cause problems if people are used to using Source Safe and just assume that a file is locked when they check it out. Of particular importance is the newline problem that I previously mentioned, which causes CVS to assume that every line has been changed, because if two people modify the same file and then check it in, CVS won't know how to merge it, and we have lost changes because of this.

This is incorrect.

Visual SourceSafe supports multiple checkouts; the feature is merely disabled in the default configuration.

Yeesh! and an update

[Snowfox]

from the migrating-your-code-repositories dept.

Also from the 16-days-between-submission-and-posting department. :)

I'm still looking around at various source control options. Perforce is the current favorite, owing to a combination of a good feature list and a number of my team's programmers having prior experience with it. The big things holding it back are the cost (over $500/seat/year) and migration time. It's really a different beast entirely, even compared to the Visual Studio CVS plugins.

Nothing seems to handle both binary and source version control well. There are special tools for one and the other, but nothing that's strong on both. I'm a programmer, and I'm tempted to just take care of my own, moving code over to a new tool and leaving SourceSafe in place for the artists. That's not quite as mean as it sounds; artists don't do multiple checkouts, and all off-site access will be read only. Those seem to be the two big things that corrupt SourceSafe.

cvs vs SS ( pros and cons )

[Anonymous Coward]

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! )

Have you tried Perforce

[Johnsiilver]

I happen to also work for a game development house, in the IT department. We have been using Sourcesafe 6 for a while now, but have found that it is often corrupting itself, not the kind of behavior that you want in your version control software. Cvs wasn't a good choice for us, being mostly a Windows shop, and Cvs isn't known to always handle certain types of multimedia files well. And there is a certain amount of comfort in having a commercial package that you can get help from[and for those who are about to flame me, I do like cvs, and I am sure there is some way to get support]. Our company has recently started using a program called Perforce for version control. Several of our projects are on it now, and we haven't heard a peep out of them as far as problems go. You can find more information at http://www.perforce.com/ . It might be a better solution that cvs, and it might not be, but it's worth evaluating.

Migrating to CVS

[swelling]

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.

Perforce

[Anonymous Coward]

SS and CVS both have significant flaws. Use Perforce. It is better balanced.

Tortoise!

[1010011010]

Tortoise is a wonderful Windows Explorer plugin that gives you access to CVS fucntionality from regular old Explorer windows.

I don't use WinCVS (except as a library) anymore, because Tortoise is so much easier!