Before I came to Microsoft, I worked in the inspection department (a double wide trailer, actually:) of what was then a Texaco oil refinery. During my employment, I helped design and implement a corrosion monitoring program that aggregated and analyzed various data inputs (UT & X-ray measurements, acid levels, chemical concentrations, temperature, etc) to help pipe and vessel inspectors identify rapidly corroding pipes before they spewed caustic petroleum goo on defenseless pipefitters or engulfed my plastic inspection trailer in a 1200 degree fireball.  Few things motivate like fear of incineration.  Anyway, having educated myself in AutoCad a few years before (late-high school LISP binge), the inspection superintendent asked me to help the department assistant/draftsperson computerize and archive the umpteen million drawings of absolutely everything in the plant.  The refinery's IT director suggested we use Visual SourceSafe to store our .dwg files.  Hoping to secure a desktop with more than 48megs of RAM, I did so without question.  Several AutoCad plug-ins have since been released that provide integrated versioning and source control for the AutoCad environment.  But back then, we just used VSS and AutoCad separately.

When I joined the SourceSafe team three years ago, I was surprised to learn that few of my new team members really knew how many NON-software developers use VSS and how diverse and critical are its uses. I assure you, they know now.

Source control is no longer the exclusive domain of hardcore software developers. However, source control applications like Visual SourceSafe were designed for and are particularly useful for software developers OR computer professionals whose files are primarily text-based (UTF-8, ANSI, etc)!

SourceSafe is designed to allow two or more individuals to work on the same file at the same time...as long as those files are non-binary. If multiple checkouts are enabled (which is not but perhaps should be the default setting*), when a user checks in their locally-persisted changes to a text file, SourceSafe automatically merges their edits into a single version of the file in the VSS database. If two users touched the same line of text in the same file, SourceSafe prompts them to decide which edit they want to keep.

SourceSafe doesn't even try to merge differing versions of non-text encoded files.  For binary files, such as those produced by Microsoft Word, AutoCad, and seemingly every other non-text editor around, SourceSafe can only tell whether two versions of a file are identical or not identical.  Theoretically, it's possible to merge differing versions of a single binary files. But from what I understand, binary merge algorithms are difficult to create and more importantly, must be created for every single binary format.

A reader recently asked, “I am just trying Source Safe on a computer graphics project. That means files that are by far larger than in a software development project, and a lot of them. What impact do I have to fear while the project grows? Does anyone has experience with large databases in Source Safe? I would appreciate your comment very much.“

My reply: “The maximum recommended database size is 3-4GB. That being said, my team, which authors documentation in Word, has maintained and relied upon VSS databases as large as 18Gb for several years now.
Use Exclusive Checkouts---Graphics files are binary. Neither SourceSafe nor any other source control provider that I know about can merge differences between two different versions of a binary file. Thus, you need to stick with the default (at least in VSS 6.0) exclusive checkout mode. In other words, you shouldn't enable two designers to check out the same file simultaneously. If you were developing text files, such as C# class files, you could do so.
Don't use Keyword Expansion in graphics files---The VSS keyword expansion feature was designed for text files. The introduction of VSS keywords into a binary file can corrupt it. For more info about VSS keywords, see
http://blogs.msdn.com/korbyp/posts/54209.aspx.
Analyze Weekly---You should Analyze your database once a week to resolve any data corruption issues. If you don't run Analyze on a large database regularly, doing so after a long lapse can take FOREVER. For more information about Analyze, see
http://blogs.msdn.com/korbyp/posts/54063.aspx.“

Related Posts: How To: Diff/Compare Two Labels in Visual SourceSafe, Keyword Expansion in Visual SourceSafe, and How To: Edit a File Checked Out to Another User (*wherein readers disagree with my contention that checkouts should be shared, by default).

+++++++++++++++++++
This posting is provided "AS IS" with no warranties, and confers no rights. Microsoft kann für die Richtigkeit und Vollständigkeit der Inhalte in dieser Newsgroup keine Haftung übernehmen. Este mensaje se proporciona "como está" sin garantías de ninguna clase, y no otorga ningún derecho. Ce message est fourni en l état, sans garantie d aucune sorte, et ne vous confère aucun droit. Vous assumez tous les risques liés à son utilisation. Il presente posting viene fornito così come é , senza garanzie, e non conferisce alcun diritto. ????? ?? ?????? "??? ????" ??? ?? ?????? ?? ??????, ????? ????? ?? ?????? ????.