Web Site Source Control Overview
If you have a source code control system installed on your computer that is compatible with Visual Web Developer, you can use the source code control commands that are included with Visual Web Developer to check files in and out of source control, merge files, view file history, and accomplish other source code control tasks with your Web site. For example, if you have Microsoft Visual SourceSafe (VSS) installed, you can perform VSS tasks directly in Visual Web Developer. Other providers can integrate with Visual Web Developer if they follow Visual Studio Industry Partner (VSIP) standards.
The exact behavior of source code control in Visual Web Developer depends on what source code control system you are using. All VSIP-compliant source code control systems support the base commands that are required to perform check in, check out, and other tasks. The Visual Web Developer commands and user interface for these functions are the same no matter what source code control system you are using. However, for some functions, such as merging files, Visual Web Developer simply hosts the source code control provider's own user interface, which can vary from one provider to another.
Source code control commands in Visual Web Developer are automatically enabled if Visual Web Developer is configured to use a compatible source code control provider that is installed on your computer. You might need to enable source code control functionality in Visual Web Developer by clicking Tools, Options, Source Control, Plug-In Selection and selecting the correct source control plug-in.
Source code control works with two Web application types: file system Web applications and local IIS Web applications. In both cases, you (and other developers) are generally working with copies of files in a location that you specify. When you check out a file, a copy of the file is moved from the source code control repository to your specified location.
Source code control exposes limited functionality when used with FrontPage Server Extension Web sites. Source code control does not work with FTP-deployed Web sites at all.
For remote Web applications, you cannot use source control from within the Visual Web Developer environment. Remote Web applications require FrontPage Server Extensions (FPSE) from Microsoft on the remote server, which provides limited support for source code control functionality. Therefore, to use source control with remote Web sites, your Web site project must be configured to use the source control system on the server where the files are located.
As of December 2010, Microsoft FrontPage Server Extensions (FPSE) 2002 is no longer available for Windows Vista and Windows Server 2008 RTM. If FPSE is already installed on the destination server, you can create and open remote Web site projects on that server. For information about FPSE support, see Supportability of Front Page Server Extensions 2002 running on Windows Vista and Windows Server 2008 on the Microsoft KnowledgeBase Web site.
FTP Web applications do not support source control. In an FTP Web application, all files are stored on a central server and are read and written using the FTP protocol, which does not support check-in and checkout functionality.
When you want to edit a file, you check the file out of the source control system. Checking out a file puts a read-write copy of it on your computer. When you are done editing, you check the file back into the source control system. To be able to check files out or in, you must be able to log into the source control system. For information about login credentials, contact your source code control administrator.
Visual Web Developer allows you to check files out explicitly or implicitly. For explicit checkout, you select the files to work with and issue an explicit command to check them out using the source control mechanism. For implicit checkout, you simply open a file in Visual Web Developer.
If the file has not been checked out, it is in read-only mode. When you make a change to the file, Visual Web Developer checks out the file so that you can save your changes. By default, Visual Web Developer does not prompt you before checking out the file. To enable prompts, click Tools, Options, Source Control, Environment, and then under Checked-in item behavior, select Prompt for check out in the list boxes beside On Save and On Edit. The default is Check out automatically.
You can configure Visual Web Developer not to perform implicit checkouts. Click Tools, Options, Source Control, Environment, and then under Checked-in item behavior, select Do nothing in the list boxes beside On Save and On Edit. In this case, files are opened in read-only mode. If you want to be able to save changes, you must first explicitly check out the file.
Most source code control systems allow multiple developers to check the same file out at the same time, which means that two or more developers might edit a file at the same time. Therefore, when you check in a file, the source code control system determines whether the file has been changed by someone else since you checked it out. If the file has not changed, it is checked in as usual. However, if the file has changed since you checked out your version, the source code control system attempts to merge your changes with the other changes it finds in the file.
The procedure used to perform the merge depends on what your source code control provider is. A typical scenario is as follows:
You check in a file.
The source code control system detects that the file has been changed by someone else since you last checked it out and merges your changes with the file in the repository.
The source code control system displays a dialog box highlighting the two sets of changes.
You accept or reject the changes. If you accept them, the file is checked in with the merged changes.
When you initially add a new file to the Web application, the file exists only locally on your computer. When source code control is enabled in Visual Web Developer, new files are marked with an icon in Solution Explorer indicating that the file is new. To add the file to the source code control repository, you can check it in individually. Alternatively, you can check in the file as part of the entire Web application, which will check in all checked-out files, including your new file.
While working with a Web site that is under source control, you might want to move, rename, or delete a file. It is recommended that you move, rename, or delete files using the source control mechanism while the files are checked in. The next time another developer checks out the changed file, Visual Web Developer applies the changes on their computer.
If you are a developer just joining a team and want to work with a Web site that is already under source control, you can retrieve a copy of the Web site from the repository. In source control terminology, this is sometimes referred to as synchronizing or enlisting. Synchronizing is also useful when setting up new computers or creating a backup of the files under source control.
Rather than creating a new Web application, you open the existing project from source control. After providing appropriate credentials if required, you specify a location on your local computer. Visual Web Developer then puts read-only copies of the application's files in the specified location. From that point, you can work with the files, checking them out, editing them, and checking them back in.
If a site has already been put under source control, you open it from source control rather than opening it directly on your local computer.
If you are enlisting in an individual Web site for the first time, in Visual Web Developer, click File, Open Web Site, and click the Source Control tab to enter your credentials and select a local location for the site. After you have enlisted in a Web site, Visual Web Developer works with the source control mechanism when you edit files. Enlisting stores the binding information in the local Visual Web Developer cache, indexed by the Web site name.