To report a found bug,
please, select the text with the bug and click Report a Bug or
CTRL+ENTER.
Help
system 10.5 of 29/11/2024,
©
FORESIGHT
In this article:
Selecting Place to Store Source Texts
Multiple Users Working with Same Object, Solving Conflicts
Updating Scheme and Transferring It for Testing
Recommended Scenario of Transferring Repository for Testing
Recommended Scenario of Updating Using *.pef Files
Different State of 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 the 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 getting started with VCS you need to install the following software:
Team Explorer.
Microsoft Team Foundation Server MSSCCI Provider.
In the provider dialog box ("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 in 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>) must not exceed 260 characters.
It is recommended to create an individual folder for each repository, in which a project is developed.
Before creating files in VCS you need first to set up Workspace to link location of files on the server and the local disk and then create a required 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 VCS control you need to connect other developers to the system. To do this, each developer must set up local and server path to store source texts, even if they work on the same station. Each team member should have permissions to work with the server folder where the source texts are stored. If a team member does not have permissions, this means that this developer is not included into the main project group and should contact the project administrator.
If on adding an object to VCS you have canceled 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 executed.
Conflicts occur when the 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, rechecked 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 users 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. The checkbox is selected by default, and update will include only object versions currently stored on the local drive in the folder selected when connecting repository to VCS. If the 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. The conflict can be resolved when preparing the update by confirming the update. Otherwise, an additional dialog box can be shown at the update stage where you can confirm the update or skip object(s) update.
Execute the following operations:
Check if all source texts have been sent to the server.
Determine 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.
Forward the scheme for testing.
Execute the following operations:
Check if 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 execute operation with 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, execute the following operations:
Remember last operations executed with 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 checked out in the repository, check it out in TFS; if the file is not checked out, check it in (to the defect created before).
Reconnect to the repository and try again to execute the operation with the object.
Moving and renaming objects placed to VCS:
Check manually if the object is checked out by other developers using Team Explorer (the Check Out operation is executed for this object). If the object is checked out, the other developers are to make changes (execute 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 on his workstation. Procedure of solving conflicts:
Update the repository in the navigator.
Find the moved object in the navigator and get the latest version of the folder that contains this object.
Execute Check In for the object.
Choose method of resolving 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 for executing 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 dialog box that opens 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 required server and define VCS server settings. If required, create new folders on server and on the local drive.
Add required objects from the repository to version control system.
Click the Configure button in the dialog box that opens. In the dialog box that opens select required server and change settings defined for VCS server; indicate the folders prepared as follows as server folder and local drive 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 drive: C:\MODULES\SCHEME_CLONE.
Copy contents 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 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.
Executing 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 execute the Reconcile command in the context menu for these objects.
In the Source Control Explorer execute the Refresh command for the NAPR folder.
In the Source Control Explorer execute Check In Pending Changes for the folder NAPR\SCHEME_CLONE, in the dialog box that opens 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 the MODULE unit is moved from the FOLDER1 folder to the FOLDER2 folder.
In the folder C:\MODULES\SCHEME_CLONE move the files related to this unit (MODULE_MODULE.text and MODULE_MODULE.ref.xml) from the FOLDER1 folder to the FOLDER2 folder.
The MODULE unit in the original scheme has been modified.
Manually correct contents of the files MODULE_MODULE.text and MODULE_MODULE.ref.xm in C:\MODULES\SCHEME_CLONE in accordance with the state of the unit in the clone scheme.
The MODULE unit is deleted from the original scheme.
In the C:\MODULE\SCHEME_CLONE folder create the files MODULE_MODULE.text and MODULE_MODULE.ref.xml where required and correctly fill in their contents.
To avoid the above mentioned problems it is recommended to make a local copy of files from 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: