When performing a comparison between metadata stored in a version controlled repository against either a target Salesforce org or another repository, we occasionally get questions about why some expected metadata differences don’t appear in the comparison results.
Two reasons typically account for the results of the comparison not maybe being in line with expectations:
- Gearset currently defaults to v37 of the Metadata API when comparing metadata stored in version control repositories. A difference between the API version of the source and target metadata can lead to unexpected differences being returned. This can easily be corrected by explicitly setting the API version to use via Gearset’s customize comparison filter feature to override the default.
- The second most common reason for apparent discrepancies is when a package.xml file already exists in the source repository and Gearset filters the items in the comparison based on the rules in the package.xml.
What’s the significance of an existing package.xml in a respository?
When a comparison is performed in Gearset using a repository as the source, the default behaviour is to use any detected package.xml as a filter; so only items allowed by the package.xml rules will be shown in the results grid.
If your package.xml rules are overly specific, you may see only a subset of differences due to a comparison filter being applied, thus leading to questions about why some expected differences are not being displayed. Note: You can also create customized filters in Gearset to limit the number of metadata types to include in the comparison. This can also reduce the number of results returned.
New in Gearset: explicitly specifying to filter comparison results if a package.xml file exists
We’ve now added the ability to choose whether to use an existing package.xml file when comparing from a repository, or to ignore the file and show all of the results from the comparison. You can do this by simply selecting your preferred behaviour when setting the source repository location of your metadata.
Ignoring any existing package.xml file will give you a complete view of all the differences between your source and target Salesforce metadata.
If you’ve got any questions or feedback, visit our feedback forum to add your comments and suggestions, or drop us an email at [email protected].