We use SourceSafe 6.0d and have a DB that is about 1.6GB. We haven't had any problems yet, and there is no plan to change source control programs right now, but how big can the SourceSafe database be before it becomes an issue?
Thanks
+1
A:
Sourcesafe recommends 3-5G with a "don't ever go over 13G".
In practice, however, ours is over 20G and seems to be running fine.
The larger you get, Analyze will find more and more problems including lost files, etc.
EDIT: Here is the official word: http://msdn.microsoft.com/en-us/library/bb509342(VS.80).aspx
BoltBait
2008-11-13 19:45:27
Aren't "ours is over 20G and seems to be running fine" and "The larger you get, Analyze will find more and more problems including lost files, etc" saying different things?
Michael Burr
2008-11-13 20:02:38
BoltBait is onto it here. You'll find SVN not too difficult to setup and it's an order of magnitude or two more comfortable to work with and AnkhSVN is quite good for SVN integration. http://ankhsvn.open.collab.net/
JTew
2008-11-13 20:03:56
@Mike B: Pretty much. We don't actually use it much any more. All of our new projects are stored in Team Foundation Server.
BoltBait
2008-11-13 20:11:49
+2
A:
I've actually run a vss db that was around 40 gig. I don't recommend it, but it is possible. Really the larger you let it go, the more you're playing with fire. I've heard instances where the db gets corrupted, and the items in source control were unrecoverable. I would definately back it up on a daily basis and start looking to change source control systems. Having been in the position of the guy who they call when it fails, I can tell you that it will really start to get stressful when you realize that it could just go down and never come back.
Kevin
2008-11-13 19:48:41
+1
A:
Considering the amount of problems SourceSafe can generate on its own, I would say the size has to be in the category "Present on disk" for it to develop problems.
Lasse V. Karlsen
2008-11-13 19:53:19
The sad thing is that it's true. I maintained a VSS database for a few years. It was less than a gigabyte. I backed it up and ran analyze on it every night and it still had odd random problems every few weeks.
Ferruccio
2008-11-14 02:24:56
+8
A:
I've had VSS problems start as low as 1.5-2.0 gigs.
The meta-answer is, don't use it. VSS is far inferior to a half-dozen alternatives that you have at your fingertips. Part of source control is supposed to be ensuring the integrity of your repository. If one of the fundamental assumptions of your source control tool is that you never know when it will start degrading data integrity, then you have a tool that invalidates its own purpose.
I have not seen a professional software house using VSS in almost a decade.
Well said without simply bashing. The idea that you need to regularly run `analyze` because you're going to get corruption that needs fixing on a regular basis seems insane to me. This is quite different than, "you need to backup because disaster could occur".
Michael Burr
2008-11-13 20:10:45
+2
A:
Do you run the built-in ssarchive utility to make backups? If so, 2GB is the maximum size that can be restored. (http://social.msdn.microsoft.com/Forums/en-US/vssourcecontrol/thread/6e01e116-06fe-4621-abd9-ceb8e349f884/)
NOTE: the ssarchive program won't tell you this; it's just that if you try to restore a DB over 2GB, it will fail. Beware! All these guys who are telling you that they are running fine with larger DB are either using another archive program, or they haven't tested the restore feature.
Brandon Corfman
2008-11-13 20:15:28
Or we archive smaller subsets, which is what my shop does. (At least, until we justify the time to move ourselves to TFS, which will hopefully be 1st quarter '09!)
John Rudy
2008-11-13 21:02:15
+1
A:
I have found that Analyze/Fix starts getting annoyingly slow at around 2G on a reasonably powerful server. We run Analyze once per month on databases that are used by 20 or so developers. The utility finds occasional fixes to perform, but actual use has been basically problem free for years at my workplace.
The main thing according to Microsoft is make sure you never run out of disk space, whatever the size of the database.
http://msdn.microsoft.com/en-us/library/bb509342(VS.80).aspx
quote: Do not allow Visual SourceSafe or the Analyze tool to run out of disk space while running. Running out of disk space in the middle of a complex operation can create serious database corruption
HeathenWorld
2009-05-13 01:41:03