In this article:
Select a Place to Store Source Texts
Multiple Users Working with Same Object, Solving Conflicts
Updating Scheme and Transferring it for Testing
Recommended Scenario of Transferring a Repository for Testing
Recommended Scenario of Updating Using *.pef Files
Different State of an Object in Repository and on VCS Server
Moving Objects Controlled by VCS
Article number: KB000022
This article discusses main points on using VCS in Foresight Analytics Platform. The article is intended for those users who have experience of working with VCS in the Visual Studio 2010 environment. It is also recommended to study the VCS described in documentation for Foresight Analytics Platform:
The article does not describe methods of using VCS in Foresight Analytics Platform, but things that are necessary to know when using this system.
Team Foundation Server (TFS) is a Microsoft product representing a complex solution that combines version control system (VCS), data collection, report creation, and tracing statuses and changes in a project. It makes easier to work together on software development. This product is available as an individual application as well as a server platform for Visual Studio Team System (VSTS).
Prior to working with the VCS you need to install the following software:
Team Explorer
Microsoft Team Foundation Server MSSCCI Provider
In the provider dialog ("Choose Folder in Team Foundation Server") select the place where source texts must be stored on server and on a local workstation. As a rule, a project is created on the TFS (server administrators are responsible for it) and all source texts are stored within this project.
NOTE. MSSCCI Provider determines limits for maximum path to local files. Path to a file ( <local folder selected in the VCS connection settings >\<generated file name>) cannot be more than 260 characters.
It is recommended to create an individual folder for each repository in which a project is developed.
Before creating files in the VCS you need first to configure Workspace so that to link location of files on the server and the local disk, and then create a desired folder.
It is forbidden to create several repositories in the same folder or in child folders. If the Invalid Project Mapped error occurs when you try to confirm location of source texts, this means that the local folder is already used to store other source texts.
If the OK button is unavailable after you have specified file paths (Server Path, Local Path), this is a TFS error that can be avoided by using MSSCCI Provider and Team Explorer versions 2008.
On connecting to a configured repository provider is initialized and the system connects to TFS server, which usually takes some time (2 to 8 seconds). The provider is initialized only when Foresight Analytics Platform is started by running the Studio.exe file.
When a repository is placed under the VCS control you need to connect other developers to the system. To do this each developer must configure local and server path to store source texts, even if they work on the same station. Each team member should have enough rights to work with the server folder where the source texts are stored. If a team member does not have enough permissions, this means that this developer is not included into the main project group and should address project administrator.
If adding an object to VCS you have cancelled Check In (changes confirmation) for operation of adding files to the TFS server, the object is still marked as added to TFS. The files are to be sent to the server when the next Check In operation is performed.
Conflicts occur when a user sends source texts to the servers and another user attempts to send his changes without taking into account changes made by the first user.
After solving the conflict the result is to be saved to the local disk, re-checked by the user and sent to the server again.
As a rule no problems arise due to application code, when such a conflict occurs. The problems arise when a conflict lies in form design, that is in the file *.form.xml. In this case it is recommended to roll back either server changes or local changes. It is not recommended to solve the conflict automatically or manually (using Merge Tool). If you make a mistake in the file *.form.xml the form designer will incorrectly respond to corrections. To solve the problem, open the local file *.form.xml and fix it manually based on modifications made in Merge Tool. You can also fix the error in the Source Control window of the Visual Studio 2008 (installed with Team Explorer 2008)), for example, to replace the current file with the latest version from the server. Check In/Check Out state for server files and repository files should be the same.
Remember that all local changes made by used that have not been sent to the server are not to be sent to dump. After you have created a clone scheme controlled by VCS, you need to disconnect this scheme from VCS.
When creating an update containing repository forms, assemblies, and units, the program takes into account the Use Local Versions of VCS Objects checkbox in update parameters. By default this checkbox is selected, and update will include only object versions currently stored on the local disk in the folder selected when connecting repository to VCS. If this checkbox is deselected, the versions currently available in version control system are to be saved to the update.
If you install update for a version stored in VCS from a version not connected to VCS, the following conflict is generated for the objects available in VCS: Corresponding object is under VCS control. This conflict can be solved when preparing the update by confirming the update. Otherwise, an additional dialog box can be shown on the update stage, where you can confirm the update or skip object(s) update.
You need to do the following:
Check whether all source texts have been sent to the server.
Define whether the current version is contained on the server. If required, send the current version to TFS.
Dump database.
Restore dump to another database.
Connect to the expanded scheme and disconnect it from VCS control.
Forward the scheme for testing.
You need to do the following:
Check whether all changes related to updated objects have been published on the server. If required, send the current version to TFS.
Create an update.
Install the update on the cloned scheme.
Check updated objects in the tested scheme and the scheme under development. The objects are to be identical.
Sometimes the following errors occur when you perform operation on an object under VCS: "Access denied", "SCC_FILENOTCHECKOUT" and so on. As a rule, this is caused by different state of the object in the repository and of its files (or some of the files). This can be checked using the Source Control window. If the error is caused by differences between the object and its files you need to do the following:
Remember last operations performed on the object and add a Defect.
In the Source Control window, bring the files corresponding to this object into the line with the state of repository objects. If the file is blocked in the repository you need to perform Check Out operation in TFS, if the file is not blocked perform Check In (to the Defect created before).
Reconnect to the repository and try again to perform this operation.
Moving and renaming objects placed to VCS:
Check manually whether the object is blocked by other developers using Team Explorer (Check Out operation is performed for this object). If the object is blocked the other developers are to make changes (perform Check In).
Move or rename the object.
Notify other application developers.
Other developers should update the navigator and get latest version of the folders from which and to which the object was moved. If the repository is small it is recommended to get latest version of root folder of the repository.
A conflict will arise if you do not follow these recommendations. A developer who receives the following message: TF10141: No files checked in: resolve the conflicts and try again, solves the conflict at his workstation. Procedure of solving conflicts:
Update the repository in navigator.
Find the moved object on navigator and get the latest version of the folder that contains this object.
Perform Check In for the object.
Choose method of solving the conflict in the dialog box that opens. When auto solving is selected, the dialog box requests a new name for the file. Specify name of file from the server.
When moving objects, groups of objects or folders with objects placed to VCS, these objects are to be moved to repositories, on the TFS sever and locally. Thus, multiple provider windows open one after another to confirm file renaming (Check In). For example, when moving a form the dialog box foe performing Check In is opened three times as three files are stored for the form. The same happens when you rename an object or change its identifier.
It is not recommended to cancel object moving in the Check In dialog box.
The problem with opening multiple dialog boxes for executing Check In when moving or renaming objects is solved within the requirement 56060.
When working with VCS you may face the situation when you need to create a clone of a scheme connected to VCS. This clone is also to be added to VCS. This may require when working with a schema is divided into two separate work-streams.
Consider example. Structure of a company includes a certain Division. Schemes of this Division are stored on TFS server in folder NAPR, and the Local Path for this folder is set to C:\MODULES.
Schemes of the Division include the SCHEME, that is stored on the server in NAPR\SCHEME. Locally files are stored in C:\MODULES\SCHEME.
To correctly clone the SCHEME to SCHEME_CLONE and connect the clone to VCS, make the following steps (you will need the rights to edit objects using Source Control Explorer):
Dump SCHEME and restore the dump the SCHEME_CLONE.
In Foresight Analytics Platform connect to the SCHEME_CLONE scheme and select the Parameters - Application Development menu item.
Next the following options are available:
In the opened dialog box click the Disconnect From Version Control System button. All settings defined for VCS connection are removed for the repository and all its objects.
In the Application Development dialog box click the Connect To Version Control System button. In the dialog box that opens select desired server and define settings of the VCS server. If required, create new folders on server and on the local disk.
Add desired objects from the repository to version control system.
Click the Configure button in the opened dialog box. In this dialog box select desired server and change settings defined for VCS server; indicate the folders prepared as follows as server folder and local disk folder:
Using the Source Control Explorer create new folder SCHEME_CLONE in the NAPR folder on TFS server (use the New Folder command). The following folder is automatically created on the local disk: C:\MODULES\SCHEME_CLONE.
Copy content of the folder C:\MODULES\SCHEME to the folder C:\MODULES\SCHEME_CLONE. In the end internal hierarchy of these folders should be the same.
Use the Source Control Explorer for the folder NAPR\SCHEME_CLONE to run the Compare command.
Specify C:\MODULES\SCHEME_CLONE in Target Path in the opened dialog box, leave the Source Path the same. Select the Show Items That Exist Only In Target Path checkbox and deselect other checkboxes. Click the OK button.
Running of the Compare command creates the list of files that exist locally in C:\MODULES\SCHEME_CLONE but are lacking on the TFS server in NAPR\SCHEME_CLONE. In this example the list includes all files and folders from C:\MODULES\SCHEME_CLONE.
Select all the found objects and run the Reconcile command in the context menu for these objects.
In the Source Control Explorer run the Refresh command for the NAPR folder.
In the Source Control Explorer perform Check In Pending Changes for the folder NAPR\SCHEME_CLONE, in the pop-up dialog box confirm sending files to server. After this C:\MODULES\SCHEME_CLONE and NAPR\SCHEME_CLONE on the server contain identical files and folders.
Sometimes you may need to connect a clone scheme to VCS after a certain time after cloning. It is possible that some files in original scheme that were added to VCS earlier, have already been modified, moved or deleted. In this case it is not enough to copy files from C:\MODULES\SCHEME to C:\MODULES\SCHEME_CLONE locally.
This problem can be solved by bringing the files in C:\MODULES\SCHEME_CLONE in line with the files in the SCHEME_CLONE repository after copying the files locally:
In original scheme MODULE is moved from FOLDER1 to FOLDER2.
In the C:\MODULES\SCHEME_CLONE folder move the files related to this unit (MODULE_MODULE.text and MODULE_MODULE.ref.xml), from FOLDER1 to FOLDER2.
The MODULE unit in the original scheme has been modified.
Manually update contents of MODULE_MODULE.text and MODULE_MODULE.ref.xm in C:\MODULES\SCHEME_CLONE in accordance with the state of this unit in clone scheme.
The MODULE unit is deleted from the original scheme.
In the C:\MODULE\SCHEME_CLONE folder create files MODULE_MODULE.text and MODULE_MODULE.ref.xml where required, and correctly fill in their content.
To avoid the above mentioned problems it is recommended to make a local copy of C:\MODULES\SCHEME to C:\MODULES\SCHEME_CLONE right after scheme cloning even if you do not intend to connect the scheme to repository.
See also: