Moving from Source Safe to CVS? 32
"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?"
Source "Safe" ? (Score:3, Insightful)
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 (Score:2, Interesting)
The other advantage of this was we got to build a nice linux box and put it in the 'officially supported' rack.. heh.
HTH.
Tortoise! (Score:2)
I don't use WinCVS (except as a library) anymore, because Tortoise is so much easier!
TortoiseCVS (Score:1)
http://www.wincvs.org/TortoiseCVS/index.shtml [wincvs.org]
Re:CVS is your friend (Score:2)
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 (Score:2, Informative)
I haven't used this myself but surfing over to the WinCVS website [wincvs.org], I found cvsscc [home.net]. It's a project to map the scc stuff that MS uses to cvs. Another attempt, perhaps more mature, is Jalindi Igloo [jalindi.com]. 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 (Score:3, Flamebait)
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 (Score:1)
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.
Re: Jalindi Igloo (Score:2)
This is incorrect.
Visual SourceSafe supports multiple checkouts; the feature is merely disabled in the default configuration.
SmartCVS and build tools (Score:4, Informative)
One thing that you should promote about the move is the number of tools that are available for CVS. For instance, there's CVSWeb [fh-heilbronn.de]. It's a web frontend. There's CVS Search [sourceforge.net] which lets you search through comments, etc. A search of freshmeat [freshmeat.net] comes up with a lot of choices.
Finally, remember that there are scripts to help migrate from VSS to CVS. vss-to-cvs [alexm.here.ru]
-Dave
PVCS (Score:2)
Ease of use was definitely the biggest reason I liked it. Check them out if you're shopping around.
Re:PVCS (Score:1)
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 (Score:4, Informative)
For the coder CVS is fantastic. CVSWeb [http], bonsai [http], and (my favorite) LXR [http] 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 [http]) 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 (Score:2)
Proper links (Score:1)
Re:CVS vs SourceSafe (Score:1)
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 (Score:1)
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 [bitkeeper.com]. It has it's limits, and we where definitely pushing them
Re:many active developers using CVS (Score:2)
SourceSafe will have problems before CVS will have problems.
So that shouldn't be too much of a concern.
Bitching and Moaning (Score:3, Insightful)
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 (Score:1)
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 (Score:3, Interesting)
Subversion is getting close (Score:1, Informative)
SourceForge? (Score:1)
Try Cervisia (Score:1, Insightful)
Regards
Maurizio
OT: How about Excel? (Score:2)
Yeesh! and an update (Score:2)
Also from the 16-days-between-submission-and-posting department. :)
I'm still looking around at various source control options. Perforce [perforce.com] 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 ) (Score:1, Insightful)
- 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 (Score:2, Informative)
Migrating to CVS (Score:3, Insightful)
On a final note, a previous poster recommended PVCS. Believe none of this. PVCS is complete trash; the client is slow, buggy and unstable.