An element, such as a table, is stored down at the field level. Changes to a field will only place that field in the current layer. This also means that the same table can have two different fields in different models in the same layer. When we export a model, it will only export the changes within that model; any fields that are in the model will not be exported. This is by design, and has many benefits when deploying a release or applying a hotfix.
TFS integration is file-based and works by AX, exporting an XPO of each element to the local repository when the element is saved. The link between the file and AX is held at the element level, as shown in the following example from our local development environment:
Data DictionaryTablesConFMSVehicleGroup maps to C:ProjectsVCSAX6015GettingStartedConFleetManagementData DictionaryTables ConFMSVehicleGroup.xpo.
Even though the resulting XPO will only contain the changes, it means the changes in the layer, not the specific model.
To demonstrate what happens with version control when we add a field to an element in a different model, follow these steps:
- Check out the
ConFMSVehicleGrouptable. - Add a new field to this table by dragging the
CustAccountEDT onto its Fields node. - Save the table and ensure that the new field's model is
USR Model. - Check in the table.
Open the XPO for the table under the ConFleetManagement model's folder structure, and you'll see that the new field will be there. The folder structure for USR Model will not contain the element at all.
This means that an element must only be in one model—we must not have fields, methods, or controls in different models in the same layer. This is good practice and should not be considered as a limitation.
In terms of layers, there is a technical limitation where elements under source control must not also be modified in a higher layer. For example, if we are working in the VAR layer, the same object must not also be in the USR layer. This shouldn't pose a practical problem in normal deployment procedures.
For example, where the VAR has vertical solutions or add-ons, they should be brought in at the lowest layer possible (ISV or VAR), and the modifications made under source control should be made in the layer above that, such as the VAR or CUS layer.
If the customer also has an internal development team working on a separate functionality set in a separate layer, such as the USR, their environment will be built from the partner or ISV supplier models, and when ready for deployment, they will move their model to the build server.