tfsversion-controltfsbuildaxaptadynamics-ax-2012

How to move AX 2012 Version Control TFS to another server keeping the same Sync Repository configuration?


My Dynamics AX 2012 DEV environment is attached to TFS - Team foundation server.

I moved the AX AOS to another Server (keeping the same SQL database Data and Model), in this way I copied in to new server my previous Repository, and I attached again the environment to the TFS.

enter image description here

My main issue, if I try to execute the TFS Sync the process starts all over again by doing the GatLatest everything (usually it goes wrong, due to too many objects to manage).

Making a small recap, I have the same SQL Database;Model;Repository;User, but change only the Server.

There is any way to keep and start in to the new server exactly like in the old server? There is some point in the system that was saved where to start the synchronization

Thanks in advance


Solution

  • My main issue, if I try to execute the TFS Sync the process starts all over again by doing the GatLatest everything (usually it goes wrong, due to too many objects to manage).

    Not sure what exactly "goes wrong" in your environment, but in essence, what the TFS Sync does is comparing the files + their timestamps in your local workspace with those in the central repository.

    If the central repository has "newer" files (i.e. their timestamps are greater than those in your local workspace), they'd be synced/downloaded to your local workspace even if the content of the files hasn't changed.

    If your local files are "newer" (their timestamps are greater, irrespective of the file content) then they would be overwritten with the files from the central repository only if a "force sync" is used - a standard sync wouldn't update them.

    Generally, in case of any issues it's a good idea to do a "force sync" first, to establish a baseline. Although it could be done from AX, I often find doing a TFS sync from Visual Studio and full compile / DB sync from AX more suitable and allowing for a greater control, especially when specific issues need to be investigated and resolved.

    At times, there could be tricky issues (e.g. when you delete a table and create a view with the same name and check it in one environment, then syncing this to another environment could fail, some manual intervention could be required), however not knowing what exactly "usually goes wrong" for you it's hard to give a meaningful advice - I'd suggest you to create a question with error details, screenshots, etc.