VSS 2005 integrates with Visual Studio's OpenProject dialogs. To open a project/solution from source control in VisualStudio 2005, the File/Open/Project... dialog should be used, click on the SourceSafe icon in the bottom of the dialog, and then you can navigate the VSS database content and locate the project or solution With VSS 6.0, open from source control can be done using special menu items File/SourceControl/OpenFromSourceControl. Similar things are true for adding an existing project from source control to the current solution. in VSS2005 you can use File/Add/Project dialog, while with VSS6 you have to use File/SourceControl/AddProjectFromSourceControl menu item.
With VSS 2005, to add an existing item from source control you can right click the project node, use Add/ExistingItem dialog, then click the SourceSafe icon in the bottom left of the dialog, navigate and select the desired file. This seems natural to use, and is possible because VSS2005 integrates with the AddItem dialog.
With VSS 6.0, to add an existing item from source control the File/SourceControl/Share... menu item has to be used to share the file from the VSS database into the current's project folder, and then add the shared file to the project.
Opening projects from source control with VSS 2005 is done asynchronously. While Visual Studio continue opening the projects from source control the user can work with the solution (getting specific files in projects or editing files already retrieved).
When VSS 6.0 is used as source control provider, the user is blocked and has to wait until VisualStudio completes opening the solution from source control. To me, this is a minor difference - I don't work with extremely large solutions; even more, open from source control is not an operation that I do daily.
VSS 6.0 was not designed to work over slow connections. Using VSS 6.0 over a modem connection may be overkill. If such configuration is needed, users often have to buy 3rd party products providing remote access functionality to VSS databases. VSS 2005 has an additional source control provider plugin, VSS Internet, that can be used with Visual Studio for slow connections; 3rd party products may not be needed.
SourceSafe 6.0 can only store, diff and merge ANSI files. Unicode files are stored in the VSS database as binary files, and they cannot be merged. UTF-8 files are stored as multi-byte characters ANSI files, which sometimes may cause corruption (if the file uses non-English code page characters). SourceSafe 2005 adds full Unicode and UTF-8 support for file contents, and allows selecting the code pages for ANSI files, which makes it the recommended source control provider if you use files with non-English characters in your projects.
- VSS2005 allows seeing which files have newer version in the database before the Get operation is done, and the Get operation will not be performed for files that don't need updating.
- VSS2005 allows seeing files deleted and renamed by other users in the VSS database, and VS will be able to synchronize locally those deletions/renames when the Get operation is performed. With VSS6, all files deleted or renamed in the database will appear as new files added locally (uncontrolled). Those files will appear in Pending Checkins Widnow, and it will be easy to check them back in by mistake. Visual Studio will allow making writable and editing those local files. You may end up making changes in files that have been already deleted in the database; if you make changes in files that have been renamed in the database you will need to redo those changes in the new files, after getting the file with the new names.
- VSS2005 allows seeing files that have been added by other users in the VSS database. This is a bigger problem for web projects, which don't have a project file to track which files are part of the project. With VSS 6.0, you can only see in Get dialog files that are in folders that also exist locally. To get all the new files in web projects, with VSS 6.0 you have to use GetLatestVersion command on the web project root folder.
Here is an example:
I have a solution containing a website and a classlibrary application. Another user has opened the solution from source control, and made the following changes:
- added a file TextFile4.txt in the web
- created a folder NewFolder in the web and added a TextFile.txt into it
- checked out and modified TextFile1.txt in the web
- deleted Class2.vb from the ClassLibrary project and propagated the change in the database
- renamed Class3.vb in the ClassLibrary project into Class3Renamed.cs and propagated the change in the database
- checked in all these changes
With VSS2005 used as the source control provider, when I open the Get dialog, I see all these changes listed:
Here is how the Get dialog looks like when VSS6.0 is used as the source control provider:
Notice that VSS6 doesn't know TextFile2.txt and TextFile3.txt are not modified, it doesn't know that Class2.vb was deleted, or that Class3.vb was renamed. For webs, VS can show that TextFile4.txt was added, but that's just because it was added into a folder that also exists locally. A file added into NewFolder is not detected as added into the website. VSS6 can only propose to do "Get latest version" for all files (which will do nothing for deleted and renamed files). New files added on server can be get locally only by doing the Get on the web project node or on the solution node.
The SolutionExplorer and PendingCheckins window look the same for both VSS 6.0 and VSS 2005, showing the deleted and renamed files as "local added", but while VSS6 will let you edit the files or check them in by mistake without any warning, with VSS 2005 you'll get prompts like this when attempting to checkin or checkout the files.
The experience with VSS 6.0 in VS2005 is no different from VS2003. However, VSS2005 improves this experience.
VSS 6.0 will get the latest version of files when doing a checkout. However, users often work disconnected, or change the files attributes and edit local files without checking out the files (when the source control database is not available). This may cause problems if there is a newer version available on the server when the users attempt the real checkout. Savvy users have to manually merge their local chnages with the latest version on the server. To workaround the problem, checkout without getting local version is used sometimes, leading to checkin without knowledge older versions of the files. To end up these problems, VSS 2005 allows checking out local version of files. If you're working disconnected, or editing files in memory, or editing files on disk without checking them out first, you'll find this new feature a good addition, and will save you from losing changes when the files are checked out.