Kevin.Gao.Blog

SourceAnywhere: A SQL Server-based version control software designed to be a replacement of Microsoft Visual SourceSafe (VSS). It is developed for both local and geographically distributed development teams.

SourceAnywhere Hosted: Sign Up

SourceAnywhere Standalone: Free Trial Download

Subversion (SVN): An open-source revision control system, which aims to be a compelling replacement for CVS.

Both SourceAnywhere and Subversion are great version control products. So which one is the right product for you?

SourceAnywhere is THE ONE for Experienced VSS Users.

If you are an experienced Visual SourceSafe user, SourceAnywhere is definitely the right choice. First, all your source code history can be easily imported to SourceAnywhere. Second, the resembling user interface makes developers’ learning curve almost zero.

Otherwise, it depends on which working mode you prefer. Typical working flow in SourceAnywhere is “(multi) check-out — edit — (merge) check-in”, while typical working flow in SubVersion is “edit local copy — (merge) commit to server”. In another word, with SourceAnywhere, when you edit a file, you know whether other people is also editing it. With SubVersion, you don’t know.

More detailed comparison follows. I will try to be unbiased in the comparison. Comments which disagree with me are well welcomed.

Where Subversion is better than SourceAnywhere

If any of the following situations apply to you, I recommend Subversion:

• Command Line SubVersion Command Line is suitable for auto scripting. Although SourceAnywhere provides Command Line Client as well as Java GUI Client, SourceAnywhere’s main focus is for IDE integration on Windows platforms. If you are working on OS X, Subversion command line provides better flexibility.
• Open Source Project SubVersion suites well for personal and open source projects. Subversion, released under an Apache-style license, is an open source system. People can get a version control system with no regard to cost.
• Integration with Windows Explorer Subversion supports integration with Windows Explorer while SourceAnywhere does not.
• Third Party SupportSVN is better supported among third party tools. For example, Hudson and Redmine.

Where SourceAnywhere is better than Subversion

If any of the following situations apply to you, I recommend SourceAnywhere Standalone:

• Tech Support Dynamsoft provides phone, email, forum, and 16 hours per weekday online chatting support. For the difficult issues, an online meeting session will be scheduled. A developer from the R&D team is involved when necessary.And, all the tech support is free.
• Microsoft Platform Support Dynamsoft is a Microsoft Gold Certified Partner. SourceAnywhere passed Optimized for Microsoft Visual Studio, Certified for Windows Vista, and Certified for Windows Server. SourceAnywhere offers better integration with Microsoft products than Subversion.
• Security Powered with SSL Protocol, Sophisticated Password Policy, Database Encryption, IP & MAC Filter Rules and other security tactics, SourceAnywhere Hosted online source control is designed to be more secure than most in-house deployment.For more information about security features, please refer to the white paper: Secure Your Source Code.
• Web development Besides of Dreamweaver integration and cross-platform access, SourceAnywhere offers a unique feature, Web Deployment through FTP. SourceAnywhere can automatically detect which files are changed, and only transfer the changed/added files.

Where SourceAnywhere and Subversion are different

• User Interface SourceAnywhere has VSS style UI. There is virtually no learning curve for developers who know Visual SourceSafe already.
• Server Setup and Maintenance SourceAnywhere Server requires Microsoft SQL Server (Express). For SVN, you need to set up either Apache2 or an “svnserve” server.
• Distributed team Both Subversion and SourceAnywhere are designed for local and distributed team. SourceAnywhere takes a step further. Its cache server can greatly improve distributed team’s productivity.
• Product integration SourceAnywhere comes with GUI client, command client, SDK, Eclipse plug-in, Visual Studio integration, Dreamweaver/flash integration, cross-platform client. All are in one product.

  Subversion comes only with core product. For IDE integration, cross-platform access and other tools integration, you need to deal with several independent sources.

All editions of Visual Studio 2010 support the source control integration feature but the Express Edition. In this article, I will demonstrate how to use version control in Visual Studio 2010. For ease of the screenshots and article writing, I take SourceAnywhere Hosted, an online version control tool, as the example. Other MSSCCI compatible or VSPackage solutions should work in a similar way.

Before everything else, we need to put our project under source control.

The first developer adds a project to Source Control

Adding a new or existing project to source control is easy:

1. Start Visual Studio 2010, and click menu Tools -> Options -> Source Control.
2. Choose your favorite in the Current source control plug-in combo box.
3. Open your project/Create a new project, and then add the project to source control by right-clicking the solution in Solution Explorer and selecting the content menu Add Solution to Source Control.

4.  Input the credentials for login and choose a server path. And the project will be added to source control successfully.

Now you can perform the basic version control operations in the right-click content menu in Solution Explorer. More commands, such as Properties, Change Source Control, etc, can be found under the menu File->Source Control.

Other developers retrieve the project from server

Most of today’s projects need the collaboration of a team. Therefore, after the first developer adds the project to source control, other developers working on the same project need to retrieve these files from server to local and possibly upload some local files to server.

To retrieve files from server, we can click menu File -> Source Control -> Open from Source Control in Visual Studio 2010. After inputting the login info, the Get Project from Dynamsoft SAW Hosted to Local dialog box is displayed. In the text box, type the desired local path or click the ellipses (…) to browse for one.



If a developer has been working on the project for some time and thus has a local project folder, I suggest he chooses a different project path other than the existing folder.

For files exist locally but not on server, we need to decide whether to share the files with other team members. If yes, we can add the files to Solution Explorer using Add | Existing Item. A yellow plus icon is displayed before the file name, and we can perform Check In to commit the files to the server.

Simultaneous development

Most of the times, developers don’t need to work on the same file at the same time. But there are situations where parallel development is needed.

Multiple check-outs
In Solution Explore, files checked out by others appear with a human glyph while files checked out by ourselves appear with a green check mark. If a file is checked out by two developers, merge happens when the second check-in is performed.
Depending on whether there are conflicts, visual merge or auto merge occurs. About how merge works for a file, you may read File Merge.

Branch

Branch can be used for many purposes, such as, a branch for a minor feature or bug, tailoring program behavior in several files for two clients who have the virtually identical needs, etc. More information can be found in Branch.

Some version control solutions, such as SCM Anywhere, support Folder Merge.

SAK and SCC (source code control) info in Visual Studio 2010

After adding a project/solution to source control in Visual Studio 2010, where is the binding info stored? The behavior depends on the design of SCC plug-ins. Some put the info within the .sln/.prj files and others write it to external MSSCCPRJ.SCC files.

Take Microsoft Visual SourceSafe for example. In older versions (previous to version 6.0c) of VSS, the binding information was stored directly in the .sln and .proj files. Since VSS 6.0c, all binding information is kept locally in MSSCCPRJ.SCC on each developer’s machine.

Most MSSCCI compatible version control solutions use the second design. When the source control binding is established, some lines similar to the followings are added to the .sln files.

GlobalSection(SourceCodeControl) = preSolution

SccNumberOfProjects = 2
SccLocalPath0 = .
SccProjectUniqueName1 = FormsApplication1\\FormsApplication1.csproj
SccLocalPath1 = .
SccProjectFilePathRelativizedFromConnection1 = FormsApplication1\\

EndGlobalSection

And the following lines are added to the .prj files. The “SAK” might stand for Should Already Know.

<SccProjectName>SAK</SccProjectName>
<SccLocalPath>SAK</SccLocalPath>
<SccAuxPath>SAK</SccAuxPath>
<SccProvider>SAK</SccProvider>

Meanwhile, a local, client-side MSSCCPRJ.SCC file is generated by the plug-in for every directory that contains source-controlled files.