Recent from talks
Contribute something
Nothing was collected or created yet.
Microsoft Visual SourceSafe
View on Wikipedia| Visual SourceSafe | |
|---|---|
| Original author | One Tree Software |
| Developer | Microsoft |
| Initial release | 1994 |
| Final release | 2005 (8.0.50727.42)
/ October 2005 |
| Operating system | Windows |
| Type | Version control |
| License | Proprietary commercial software |
| Website | msdn |
Microsoft Visual SourceSafe (VSS) is a discontinued source control program oriented towards small software development projects. Like most source control systems, SourceSafe creates a virtual library of computer files. While most commonly used for source code, it can handle any type of file in its database, but older versions were shown[1][2] to be unstable when used to store large amounts of non-textual data, such as images and compiled executables.
History
[edit]SourceSafe was originally created by a North Carolina company called One Tree Software. One Tree SourceSafe had gone through several releases in their 1.x to 2.x cycles, supporting DOS, OS/2 (with a Presentation Manager GUI), Windows, Windows NT, Mac, and Unix. When Microsoft bought OneTree in 1994,[3] they immediately ceased development on all versions except for Windows. Microsoft SourceSafe 3.1, as well as the Macintosh and 16-bit Windows versions,[4] were briefly available before Microsoft released a Version 4.0. With the acquisition of One Tree Software, Microsoft discontinued its existing source control application, Microsoft Delta.[5][6]
After the acquisition, Mainsoft Corporation developed SourceSafe for UNIX in cooperation with Microsoft.[7] Later, Metrowerks, Inc. developed Visual SourceSafe for Macintosh in cooperation with Microsoft.[8]
Overview
[edit]SourceSafe was initially not a client/server source control system, but rather a local only system. Architecturally, this serves as both a strength and weakness of design, depending on the environment it is used in. It allows a single user system to be set up with less configuration than that of some other SCM systems. In addition, the process of backing up can be as simple as copying all of the contents of a single directory tree. For multi-user environments, however, it lacks many important features found in other SCM products, including support for atomic commits of multiple files (CVS has the same problem as it is built upon the original RCS). SourceSafe inherits its shared functionality using direct remote file system access to all the files in the repository. This, together with historic bugs in the codebase, occasionally led to SourceSafe database corruption, a problem noted by Microsoft.[9]
Starting with VSS 2005, Microsoft added a client–server mode. In this mode, clients do not need write access to a SMB share where they can potentially damage the SS database. Instead, files must be accessed through the VSS client tools - the VSS windows client, the VSS command-line tool, or some application that integrates with or emulates these client tools.[citation needed]
Versions
[edit]| Version | Date |
|---|---|
| 3.1 | February 14, 1995[4] |
| 4.0 | September 12, 1995[10] |
| 5.0 | October 7, 1996[11] |
| 6.0 | June 3, 1998 [12] |
| 6.0c (Build 9350) | 2001[13] |
| 2005 | January 27, 2006 [14] |
Criticism
[edit]Visual SourceSafe's stability was criticised due to the way it used a direct, file-based access mechanism that allowed any client to modify a file in the repository after locking it. If a client machine crashed in the middle of updating a file, it could corrupt that file.[15] Many users of Visual SourceSafe mitigated this risk by making use of a Microsoft-provided utility that checked the database for corruption and, when able, corrected errors that it found.
Microsoft in-house use
[edit]Although "eating their own dog food" is often said to be part of Microsoft's culture,[16] VSS appears to be an exception; it is widely rumored[17] that very few projects within Microsoft relied on Visual SourceSafe before the product was discontinued, and that the predominant tool at the time was SourceDepot. According to Matthew Doar:[18]
Microsoft itself used an internally developed version of RCS named SLM until 1999, when it began using a version of Perforce named SourceDepot.
The Microsoft Developer Division was using Team Foundation Server for most of its internal projects,[19] although a VSS transcript[citation needed] implied that other large teams use "a mix of customized in-house tools."
Updates
[edit]An updated version, Visual SourceSafe 2005, was released in November 2005, promising improved performance and stability, better merging for Unicode and XML files, as well as the ability to check files out over HTTP. It was included with Visual Studio 2005 Team System editions,[21] but is not included with Visual Studio Team System 2008.
At the same time, Microsoft also introduced a source control called Team Foundation Version Control (TFVC), which was part of project lifecycle management product Visual Studio Team System. This product addresses many of the shortcomings of Visual SourceSafe, making it suitable for larger teams requiring high levels of stability and control over activities.
With Visual Studio 2010, Microsoft ceased distribution of Visual SourceSafe. Microsoft now offers Team Foundation Server Basic for smaller development teams.[22][23] There was a hotfix so existing customers could use SourceSafe with Visual Studio 2010.[24]
The final version of the product, Visual SourceSafe 2005, was retired from mainstream support on 10 July 2012, with extended support ending on 11 July 2017.[25]
Further reading
[edit]- Visual SourceSafe 2005 Software Configuration Management in Practice (Packt Publishing, 2007)
- Real World Software Configuration Management (Apress, 2003)
- Essential SourceSafe (Hentzenwerke Publishing, 2001)
See also
[edit]References
[edit]- ^ De Smet, Alan (2009-04-15). "Visual SourceSafe: Microsoft's Source Destruction System". Retrieved 2010-09-19.
- ^ Bolton, Michael (2003-01-28). "Visual SourceSafe Version Control: Unsafe at any Speed?". Retrieved 2010-09-19.
- ^ "Company News; Microsoft Says It Has Acquired One Tree Software". The New York Times. November 16, 1994. Retrieved 2007-11-21.
- ^ a b "MICROSOFT SHIPS SOURCESAFE SOURCE-CODE-MANAGEMENT SYSTEM". The Free Library by Farlex. Retrieved 21 May 2014.
- ^ "MICROSOFT CORPORATION ACQUIRES ONE TREE SOFTWARE". The Free Library by Farlex. Retrieved 21 May 2014.
- ^ Gross, Daniel (November 15, 1995). "Go Configure". CIO Magazine. Retrieved 21 May 2014.
- ^ "Mainsoft to ship Visual SourceSafe for UNIX". The Free Library by Farlex. Retrieved 21 May 2014.
- ^ "Metrowerks Signs Exclusive License for Microsoft Visual SourceSafe on Mac OS". The Free Library by Farlex. Retrieved 21 May 2014.
- ^ "SourceSafe database corruption". Microsoft. Retrieved 18 Dec 2014.
- ^ "MICROSOFT ANNOUNCES VISUAL SOURCESAFE, AN INTUITIVE CODE-MANAGEMENT SYSTEM". The Free Library by Farlex. Archived from the original on 2014-05-21. Retrieved 21 May 2014.
- ^ "Microsoft Announces Visual SourceSafe 5.0, An Intuitive, Project-Oriented Version Control System". Microsoft. Archived from the original on 2014-06-10. Retrieved 21 May 2014.
- ^ "Microsoft Support Lifecycle- Visual SourceSafe 6.0 Standard Edition". Microsoft Support. Microsoft. Retrieved 21 May 2014.
- ^ Microsoft Corporation (2001). "Visual SourceSafe 6.0c Readme" (
Readmess.htm). Microsoft Visual SourceSafe 6.0c [CD-ROM]. - ^ "Microsoft Support Lifecycle - Visual SourceSafe 2005 Standard Edition". Microsoft. Retrieved 21 May 2014.
- ^ "Best Practices for Preventing Data Corruption". MSDN.
- ^ "Microsoft tests its own dog food". ZDNet. CBS Interactive. July 21, 2003. Archived from the original on January 8, 2007. Retrieved October 9, 2005.
- ^ "It's all Hype. - Jerry Dennany's Occasional Clue". Weblogs.asp.net. 2003-07-15. Retrieved 2012-04-13.
- ^ Doar, Matthew B. (2005). Practical Development Environments. O'Reilly. p. 73. ISBN 0-596-00796-5.
- ^ Guckenheimer, Sam; Neno Loje (2012). Visual Studio Team Foundation Server 2012: Adopting Agile Software Practices: From Backlog to Continuous Feedback (3rd Edition) (Microsoft Windows Development Series). O'Reilly. p. 241. ISBN 978-0-321-86487-1.
- ^ Richard Chirgwin (2017-05-25). "Windows is now built on Git, but Microsoft has found some bottlenecks". The Register. Retrieved 2017-06-01.
- ^ "VS 2008 and SourceSafe Q&A - BUGBUG: poor title - Site Home - MSDN Blogs". Blogs.msdn.com. 2007-12-03. Retrieved 2012-04-13.
- ^ Krill, Paul (2009-09-30). "Microsoft looks to move SourceSafe users to newer technology | Developer World". InfoWorld. Retrieved 2012-04-13.
- ^ "Visual SourceSafe Road Map". Msdn2.microsoft.com. 22 March 2011. Retrieved 2012-04-13.
- ^ "KB976375 - TFS: VSS integration with Dev10". Archived from the original on 2010-04-16.
- ^ "Search Product and Services Lifecycle Information - Microsoft Lifecycle".
External links
[edit]Microsoft Visual SourceSafe
View on GrokipediaHistory
Origins and Early Development
Microsoft Visual SourceSafe traces its roots to SourceSafe, a version control system developed by One Tree Software, a small company based in Raleigh, North Carolina. Founded in 1992 by Brian Harry, Kenny Felder, and Larry Iverson, One Tree Software created SourceSafe as a file-based tool designed to facilitate collaborative software development by tracking changes to source code files on local file systems.[7][8] The system emphasized simplicity and accessibility for development teams, allowing multiple users to check out, edit, and check in files while maintaining version history without requiring a centralized database.[9] Early releases of SourceSafe, spanning versions 1.x through 3.x, demonstrated broad platform compatibility to appeal to diverse development environments of the era. It supported DOS for basic command-line operations, OS/2 including a Presentation Manager graphical interface, Windows and Windows NT for emerging graphical workflows, Macintosh with a dedicated client for Apple ecosystems, and Unix via an X Window System client.[10][11] This multi-platform approach enabled cross-environment code sharing, a key innovation at the time when development often spanned heterogeneous systems.[12] On November 15, 1994, Microsoft acquired One Tree Software to bolster its developer tooling portfolio, rebranding and integrating SourceSafe as Microsoft Visual SourceSafe for seamless use within the Visual Studio ecosystem.[4][3] This move directly replaced Microsoft's short-lived in-house product, Delta—a source control tool released in 1993 that had struggled commercially—positioning Visual SourceSafe as the standard for Windows-based development.[13][11] Following the acquisition, Microsoft shifted focus exclusively to Windows platforms, ceasing further development on non-Windows variants.[4]Major Milestones and Acquisition
The acquisition of One Tree Software in November 1994 allowed Microsoft to integrate SourceSafe into its ecosystem. The deal was announced on November 16, 1994, with the renamed Microsoft Visual SourceSafe scheduled for release the following month at a price of approximately $499 per user.[3] This marked a pivotal shift, as Microsoft discontinued Delta due to its limited adoption, features, and high cost.[13] Following the acquisition, Microsoft redirected SourceSafe's development toward a Windows-centric focus, ceasing support for multi-platform versions that had previously run on systems like Macintosh and Unix.[14] Visual SourceSafe quickly became the standard source control solution for small-team projects within Microsoft's developer tools, emphasizing simplicity for collaborative environments.[13] A key milestone occurred with Visual Studio 4.0 in 1995, where Visual SourceSafe was integrated as the default source control provider, streamlining version management directly within the IDE for the first time.[15] Further advancements in integration and features followed in subsequent releases; see [[Versions and Evolution]] for details.Overview and Architecture
Core Features
Microsoft Visual SourceSafe (VSS) primarily functioned as a file-based version control system designed for small teams, enabling developers to track changes to source code and other project files through a check-in/check-out model that employed exclusive locking by default. In this model, known as Lock-Modify-Unlock, a user would check out a file to obtain an exclusive lock, preventing others from modifying it until it was checked back in with updates, thereby minimizing conflicts in collaborative environments. This approach supported both text and binary files, maintaining a history of revisions for each item while allowing reversion to prior versions as needed.[16][17] The system's backup mechanism was straightforward, treating the entire database as a set of directories on a file share—typically including folders like \data, \users, and \temp—that could be copied directly to create redundancy without specialized tools. Administrators were advised to perform these copies during off-hours to avoid interruptions, ensuring data integrity through simple file system operations rather than complex replication. This design facilitated easy recovery but required careful management to prevent corruption during multi-user access.[18] VSS offered tight integration with Microsoft Visual Studio, allowing source control operations such as check-in, check-out, and history viewing directly from within the integrated development environment (IDE) via built-in plug-ins. This seamless embedding supported developers working on projects in languages like C++, Visual Basic, and others, with menu options in Visual Studio to interact with the VSS database without leaving the IDE. The integration extended to other Microsoft tools, enhancing workflow efficiency for Windows-based development.[19] Basic operations in VSS included limited branching, which was achieved manually through file sharing across projects or explicit branching commands, often resulting in duplicated folder structures for parallel development paths. Merging changes between branches required manual intervention, typically by comparing differences and applying updates file-by-file, lacking automated tools for complex reconciliations. Labeling provided a way to tag entire projects or files at specific points, creating snapshots for releases or milestones, such as marking a "version 1.0" build for reference. These features catered to straightforward project management but were best suited for small-scale use.[20] Introduced in the 2005 version, client-server mode enabled remote access to the VSS database over HTTP, allowing clients to connect without direct file share permissions, which improved usability for distributed teams via a web service interface. While this expanded accessibility, the underlying file-based design carried inherent risks of instability under concurrent access, as explored in technical analyses of its architecture.[21]Technical Design and Limitations
Microsoft Visual SourceSafe employs a file-based database architecture, storing source files, metadata, and version history in a shared folder structure on a Windows file system rather than a dedicated relational database server. This design encodes file names to accommodate long paths, while maintaining short 8.3 filename equivalents for compatibility with legacy FAT file systems, which imposes practical constraints on naming and storage in environments limited by older conventions.[22] The system implements an exclusive locking model known as lock-modify-unlock, where developers must explicitly check out files to edit them, creating a read-write copy in their local working folder and preventing simultaneous modifications by other users. This mechanism ensures conflict-free updates for binary files or scenarios without merge capabilities but restricts concurrent development, rendering it suitable primarily for small teams.[23] Visual SourceSafe lacks support for atomic commits, handling check-ins as independent per-file operations without underlying transaction mechanisms to ensure consistency across multiple changes. This absence heightens the risk of database corruption, particularly if network interruptions or client crashes occur mid-operation, potentially leaving the repository in an inconsistent state.[24] Due to its file-based structure and reliance on sequential file scans for operations like searches and history queries, Visual SourceSafe exhibits poor scalability with large repositories; Microsoft recommends limiting individual projects to no more than a few hundred files for acceptable performance, with the system supporting a theoretical maximum of approximately 4 billion files and projects in a database but performance degrading with large repositories overall.[22] For database maintenance, Microsoft supplies the Analyze.exe utility, a command-line tool that verifies file integrity, detects inconsistencies in metadata such as CRC mismatches, and repairs errors when invoked with the -f flag—requiring all users to be logged out to avoid conflicts during execution.[25]Versions and Evolution
Initial Releases
Microsoft's initial releases of Visual SourceSafe followed the 1994 acquisition of One Tree Software's SourceSafe product, rebranding and adapting it for broader Windows development use. Version 3.1, released on February 14, 1995, marked the first official Microsoft edition of the tool, providing basic file versioning capabilities primarily for 16-bit Windows environments and targeting small-scale development needs. This version retained the core project-oriented structure from its predecessor, enabling developers to track changes in source files through simple check-in and check-out operations without advanced networking support. Version 4.0, launched on September 12, 1995, introduced significant enhancements for integration with Microsoft's Visual Studio suite, including seamless connectivity with Visual Basic 4.0 and Visual C++ 4.0 for automated source control during IDE workflows.[26] It also added user permissions management, allowing administrators to control access levels and file properties via new commands likess properties and ss about, which displayed detailed version and ownership information.[26] Additional functionality included pinning files to specific versions (ss pin and ss unpin), merge-on-get options for resolving conflicts during retrievals, and support for UNC paths and drag-and-drop sharing to streamline local team collaborations.[26]
The October 7, 1996, announcement of Version 5.0 emphasized performance optimizations for core operations, such as faster check-in and check-out processes, making it more efficient for handling larger local repositories.[2] Key updates included a visual merge tool for point-and-click conflict resolution, enhanced project difference comparisons to synchronize team changes, and an archive utility for managing database storage by relocating or archiving projects.[2] Web-specific features were also added, like hyperlink checking, a deploy command for publishing content, and sitemap generation, extending its utility to early Web development tasks.[2]
Version 6.0, released on June 3, 1998, as part of the Visual Studio 6.0 suite, brought a graphical user interface with the introduction of the Visual SourceSafe Explorer, simplifying navigation and administration through intuitive menus and browse buttons for project comparisons.[27] It improved merging tools with features like project-level differences, a dedicated deploy command for files and projects, and the move command for reorganizing items without data loss.[28] Other additions included fast get for quicker file retrievals, label promotions for better versioning tracking, and administrative tools like database creation and temp directory cleanup, all accessible via the enhanced OLE automation interface.[28]
Throughout these initial releases from 1995 to 1998, Visual SourceSafe maintained a local-only deployment model, relying on shared file systems for collaboration and suiting individual developers or small teams without requiring dedicated server infrastructure.[26][28]
