Version Control and Visual Studio 2010
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:
- Start Visual Studio 2010, and click menu Tools -> Options -> Source Control.
- Choose your favorite in the Current source control plug-in combo box.
- 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.
- 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.
Meanwhile, a local, client-side MSSCCPRJ.SCC file is generated by the plug-in for every directory that contains source-controlled files.