Adding Objects to Version Control System

To add objects to version control system:

  1. Select objects in the object navigator or project navigator in the development environment.

  2. Execute one of the operations:

After executing the operations the added objects look different depending on the version control system in use:

A standard dialog box for adding files to version control system opens:

Depending on the selected object, different collection of files containing the object data is stored on the server and on the local computer. The file names are generated as follows: <object identifier>.<extension>.

NOTE. Team Foundation Server limits length of server version control system path. Server version control system path is the full path to a file stored in version control system. The following restrictions affect this path:

- maximum 248 Unicode characters for a directory name.

- maximum 260 Unicode characters for both directory name and file name.

Take into account this restriction when adding objects to version control system.

The object will be added to version control system without any additional confirmations. The required set of files will be created on server and in user local folder.

After the object is added to version control system, the object is locked and the object icon in the object navigator and project navigator looks as .

NOTE. Object locking is executed only in the Team Foundation Server version control system. After the object is added to version control system, it can be accessed to other developers in the read-only mode. An appropriate message is displayed on an attempt to edit such an object. To work with these objects, all developers must have the repository connected to the same version control system server. To change the object, check out it for edit.

When objects are added to version control system, a set of files containing information on the object version is saved on the server and in the local folder on the workstation.

Object Files
Resources

<identifier>.bin. File with images from resources.

<identifier>.res.xml. File with text resources.

Assembly <identifier>.ref.xml. XML file containing a list of units/forms included in this assembly.
Unit

<identifier>.ref.xml. XML file containing a list of links to system assemblies and repository assemblies.

<identifier>.text. Text file containing unit code.

Form

<identifier>.form.xml. XML file containing form parameters (size, components, components layout and parameters).

<identifier>.ref.xml. XML file containing a list of links to system assemblies and repository assemblies.

<identifier>.text. Text file containing unit code.

.NET assembly <identifier>.prop.xml. XML file containing assembly parameters and a list of connected assemblies.
.NET unit

<identifier>.prop.xml. XML file containing assembly parameters and a list of connected assemblies.

<identifier>.text. Text file containing unit code.

.NET form

<identifier>.prop.xml. XML file containing assembly parameters and a list of connected assemblies.

<identifier>.text. Text file containing form code.

A folder containing files of form child objects is also created:

  • Files of .NET form resources.

  • Files of the .NET unit containing form designer code.

NOTE. When a .NET object is added to version control system, also the parent .NET assembly and all its contents are automatically added.

Query

<identifier>.params.xml. XML file containing settings of query parameters.

<identifier>.query.xml. XML file containing query text.

View

<identifier>.params.xml. XML file containing settings of view parameters.

<identifier>.view.xml. XML file containing view text.

Procedure

<identifier>.params.xml. XML file containing settings of procedure parameters.

<identifier>.procedure.xml. XML file containing procedure text.

DBMS command

<identifier>.params.xml. XML file containing settings of DBMS command parameters.

<identifier>.sql.xml. XML file containing DBMS command text.

Moving Objects Added to Version Control System

To prevent errors that developers may encounter due to moving or renaming objects added to VCS, follow the rules:

Before moving or renaming an object make sure that this object is not locked by other developers. Use Microsoft Visual Studio Team Explorer to check this. If there are any pending changes, contact developers and inform them on the need to check in all changes. After the check an application developer may move or rename corresponding repository object. When an object is moved or renamed, the platform automatically moves or renames all server files corresponding to the object.

NOTE. When a repository object is moved or renamed, a confirmation is required to move or rename corresponding server files.

After an object have been moved or renamed, inform all application developers working on this object about it. Then the developers should refresh object navigator window, get latest version of the folder, from which the object was moved and the folder, to which the object was moved.

When a conflict arises related to pending changes in moved objects, the developer who gets the error message "TF10141: No files checked in: resolve the conflicts and try again" must resolve this conflict locally. To do this, refresh repository in the object navigator, get latest version of the folder, to which the object was moved, and check in the changes. Select the required method of conflict solving in the Resolve Conflicts dialog box. If automatic conflict solving has been selected, select the name of the file on the server in the dialog box that opens requesting the new file name.

Before moving or renaming the object get the latest version of objects from the server. After this move or rename the required repository object. When an object is moved or renamed, the platform automatically moves or renames all server files corresponding to the object.

After the object have been moved or renamed, check in changes to the server and inform all application developers working on this object about it. Then they should refresh the object navigator and get the latest version of objects from the server.

When a conflict arises related to pending changes in moved objects, the developer who gets the error message should resolve the conflict locally and check in resolved changes in objects to the server.

See also:

Developing Application in a Team | Checking Changes in the Latest Version of Objects | Getting Latest Version of Objects