Concurrent Checkout and Changes to System Definition Model (SDM) Documents
In Distributed System Designers, it is not recommended that you merge or concurrently check out SDM documents, including .sdm files and distributed system diagram (.ad, .sd, .dd, and .ldd) files, from source code control due to the structure and complexity of metadata that these documents contain. If you are using Visual Studio's version of source code control (Team Foundation or Visual SourceSafe), exclusive checkout is enabled by default and allows checkout of a file only by one user at a time.
Note
When an application that supports implementation is implemented on the application diagram, the corresponding project is generated and appears in the solution. The SDM definition for the implemented application is stored in an .sdm file and is included with the corresponding project. For more information, see Overview of the System Definition Model (SDM) and Relationships Between System Definition Model (SDM) Documents.
Application diagrams should not be merged. Once an application is implemented, the code becomes the master definition for the application and changes to the diagram and code are synchronized with each other. As application code files and configuration files are the sources for an SDM definition, the results from merging code files or configuration files ultimately determine the final version of the SDM definition in the .sdm file.
Note
In Team Foundation, you can shelve or set aside pending changes. However, this action is not recommended when it results in the need to merge SDM documents. For example, if you change settings or constraints in configuration files, shelve those changes, and then make other changes to those settings and constraints, you must merge SDM documents. For more information, see Working with Version Control Shelvesets.
Whenever the application diagram is opened or closed, relevant changes to project code are synchronized with the .sdm file and the application diagram. Therefore, if the application diagram (.ad) file or an .sdm file becomes unsynchronized with the code, you can resynchronize it by closing and reopening the application diagram. For more information, see Synchronization Across System Definition Model (SDM) Documents.
Note
Data in SDM documents that cannot be recreated from another source, for example, presentation data or SDM information stored only in .sdm files, will be permanently lost if the document is deleted, or if the information is lost as a result of a merge operation. This is the only scenario in which not merging diagram or .sdm files might result in information loss. For this reason, it is strongly recommended that you do not work concurrently on or merge definitions that are stored only in .sdm files. For example, Web content endpoints on an ASP.NET application are not reverse-engineered when a new .sdm file is regenerated for a deleted one that contained SDM information for those endpoints. For more information, see Troubleshooting Application Diagrams.
Concurrent Checkout and Changes to Application Project Files
Though not recommended, you can enable shared checkout if your team chooses to make concurrent changes to project files. However, certain scenarios might require merging those changes when checking in project files. Merge conflicts might occur and need to be resolved. For more information, see How to: Configure Check-Out Settings if you are using Team Foundation.
One such common scenario involves multiple developers working on different source code files in a shared project. This project might be shared across multiple solutions with each solution possibly containing its own application diagram. If the solution contains an application diagram, and the project contains an .sdm file, then changes or concurrent changes to code files or configuration files in the project might require updating the .sdm file. Therefore, when the project is checked in, you must merge any concurrent changes to the .sdm file or discard one set of changes to the .sdm file.
For example, suppose two developers are working in the same solution. The first developer wants to work on the Web service class file for an ASP.NET application and checks out the solution containing the application project. This developer can work on project code without opening the application diagram or any other diagrams that might exist in the solution. However, changes to code files might still affect these diagrams. If this developer opens the application diagram, the developer is prompted to check out the diagram along with any other project files required for synchronization.
Note
If the developer cancels checkout or if the diagram cannot be checked out for any reason, the diagram will lock. However, the developer can continue making changes to code. For more information, see Troubleshooting Application Diagrams.
Suppose the second developer needs to work on the same project in the same solution and checks out that project, depending on the particular source code control solution being used. However, the second developer works on a class file for a different Web service on the same application. If the second developer wants to view the application diagram to see how the changes are reflected there, then that developer can view the diagram only in a read-only state as it is already checked out to the first developer. However, the second developer can continue making changes to code through the code editor.
When either developer is finished with their changes, they check them into source code control. At this time, merge conflicts to files that are checked out at the same time must be resolved. In most cases, some changes to the .sdm file will be chosen over others, and the application diagram will synchronize with the .sdm file according to the merged code. However, in this scenario where the second developer is working on a different Web service class file, it is safe to accept one .sdm file over the other as the application diagram will synchronize with the code and then synchronize the .sdm file.
For more information, see How to: Resolve Conflicts in System Definition Model (SDM) Documents.
See Also
Concepts
Partitioning of Distributed System Solutions for Implementation