D365 - Azure Devops - Git Repo - How to check the history of a file which is stored in separate folders in the Main branch

Question

In Our company, we are developing D365 and we export each change as a patch solution, create a branch and then do a pull request and merge with the main.

The patches are merged as separate folders inside Main.

eg. I modify a file named "solution.xml" in Dynamics, create a patch, check in the patch and will be merged as "MustaqueTest_Patch_5fa28cd1\Other\Solution.xml" and in the next change to the same "solution.xml" file, after merge it will be merged under a different folder "MustaqueTest_Patch_fe90da4e\Other\Solution.xml." and likewise.

The challenge I am stuck here is to view the version changes for the file. As these are added in separate folders, I couldnt check the version history of that file.

Can you please advise how this can be done ?

Another challenge is when i checked the git diff, I had to know the sequence of checkin hierarchy to compare which is difficult.

git diff :MustaqueTest_Patch_fe90da4e/Other/Solution.xml MustaqueTest_Patch_124985mp/Other/Solution.xml

As per the latest comment, for those files in the Main, I couldnt see the commit option to check with the previous files.

Answer 1

I don't think I can provide a better way for you to compare changes across patches. However I will try provide some insight into how we track changes to solutions and some suggestions that may improve how you manage solutions in Dynamics and in source control.

Multiple Patches

... and in the next change to the same "solution.xml" file, after merge it will be merged under a different folder

If you are editing the same patch, then you should be unpacking the solution.xml into the same folder, not creating a new one. The patch will have a unique name {BaseSolutionName}_Patch_{PatchId}.

If you are creating an new patch, then this should always be unpacked into a new folder based on the unique name.

The patches are a container of changes to the base solution. I don't think you should be comparing two or more patches of the same solution so often that this is a hassle. For example, if you are modifying the Account entity main form across two patches, then

1. You should be making these changes in a single patch due to how component changes are not segregated to the solution they were made in
2. The changes you make to the form will show in both patches when then solution.xml is unpacked, as the form is included in both patches

Solution Packager Tool

As the comments on your post have mentioned, this isn't the ideal way to be tracking changes. In an ideal world you would be unpacking the entire solution and patches into source control, as separate XML files representing each component included in your patch. To do this you would use a tool such as SolutionPackager.

This tool:

... reversibly decompose a Microsoft Dataverse compressed solution file into multiple XML files and other files so that these files can be easily managed by a source control system (source)

Your patches would still exist in separate folders until you roll-up your patches into your base solution, but you can more easily compare changes made to patches.

Patch Roll-Up

When the patches are rolled up into the base solution, your patch folders should be deleted (as the no longer exist in Dynamics, so should not exist in source control). All the changes made in your patches will be represented as changes to the solution.xml in the base solution now, instead of changes in separate solution.xmls specific to each patch.

Pre-Build ALM Solution

I would highly recommend using a ALM toolset to simplify the packing, unpacking, deployment and change tracking of solution. There are many available , but I recommend Microsoft.PowerPlatform.DevOps

Hopefully this is helpful.