Understanding TFS with AX 2012 (IV)

So, at this point, you can ask yourself the question why would the Version Control Synchronize in AX fail from time to time? Because it does happen, every now and then.
The answer is that, most of the times, the developer might perform, unaware of what will be its action's outcome, some task in a manner that will leave the system inconsistent. The only exception for the scenario is when the number of changes is so great that it actually leads the system to a crawl, and possibly not getting everything in AX.

Let's take a look at some of the cases:

a) working disconnected from TFS. It can happen that the AX client will start with no TFS connection, maybe wrong setup, TFS is down, or the developer will disable source control for some task he has.
 At this point, possible actions might trigger issues in the future. These actions can be:
 - manual imports of xpo files that are containing current objects from TFS or future planned items to be added;
 - renaming or deleting objects that are in TFS;

 With these in mind let's move to the next step. This is actually where the error will appear in the Version Control Synchronize process.


 The issue: duplicate OriginId. 
 The outcome: objects not imported in AX.
 The downside: objects marked on the TFS server as Latest (TFS thinks you have the latest object), while you are actually working with old versions of the objects.

 The error messages that you will get are:

 (as a pop up window) Conflict encountered during automatic merge of changes. Please check your modifications.
 

 and

 The origin {73701EAD-8182-442B-A818-B72CA6F0A657} is not unique, it is already used by SharedProject element with name prjOne.


or

The origin {E0FD4EE4-8D32-42CA-8273-C8D9949E4F85} is not unique, it is already used by Class element with name clsOne.
. Unable to save Class clsOne
             Serious error during import of Class clsOne

The fix: identify in your instance the objects that are holding the wrong IDs. Most likely, they are not existing as valid objects in TFS anymore (they are either deleted, or renamed). SO, you can just remove them. If by any chance this is not true, then you still need to remove the object, and recreate one with the same code, that will have a different OriginId.

b) getting versions of an item from Visual Studio.
 If you do that, you must understand what this does very clear. When you do Get version, Visual Studio will download the item in your local repository folder, but it will not import this to AX. So, it is up to you to do so. You can import an object in AX as long as it's not existing in TFS, or if the Version Control is disabled. You can use this case to recover from some synchronization incident, however, it is rather difficult to manually identify objects that are missing from AX and import them. Plus, it leads to scenario a).

c) performing Synchronize with Force.
 Well, the problem with this stands in the number of objects to sync. If this is low, it will be ok. However, on large projects, the number might become so high, that eventually this will cause the import to somewhat stop at some point and will lead eventually to an unusable instance.