One of the ways to show the problems with sourcesafe is to look in the
Microsoft knowledge base for them Search for "Visual Sourcesafe kbbug"
or "Visual SourceSafe corruption" that should help you wilth reasons
not to use.
Point out that all databases MUST be analysed frequently, once per day
if the DB is busy. We ended up writing a utility to drive analyze.exe
automatically and check the logs for evidence of analysis failures.
We had around 80 VSS DBs so the tools where a necessity, Leaving this
up to IT people to do manually is asking for trouble.
Why 80 DBs you ask? Once the quantity of data or files or revisions
(its not easy to predicting the failure points) get big the DB will
failed frequently. MS use a rule of thumb of 2GB, but you can see
problems at smaller sizes.
If a client machine loses its network connect while working on a DB
it will corrupt. Plug the LAN cable or hit the power switch.
We hit problems with the automation interface and got as far as the
Redmon VSS support team only to be told that they would not fix it.
You cannot retrieve old revisions of software if you later deleted
a file in the old label from automation. This means you have to
use the command line SS or manually do all source control.
Processing history from the automation API takes around .5 seconds
per item on a LAN. So a file with 50 revisions will take 25 seconds
to list.
If you have virus protection running and it checks the files on the
VSS DB share performance will dive by a factor 20x.
All machines that touch the DB must have their time synchronized or
you will see labels fail to label the files you expect.
They said that the energy was going into a SQL based replacement,
I have no idea where they have got to with it. And as others have
said MS does not use VSS in house.
You might also like to point out that running the VSS GUI is unusable
on slow connections. A right click on a file in the GUI transfers
5M Bytes typically before the menu appears.
Barry
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Nov 8 00:24:48 2003