The current output folders generated by TabCompare are based on LUID values returned from the REST API. These are great for ensuring uniqueness, but are not easily read or used by humans trying to follow up on specific image differences they've found. Additionally, if the two servers are not based on the exact same backup file--say someone wanted to do comparisons based on content they copied over via the Content Migration Tool--then the image comparisons cannot be done, because the LUIDs between servers will not match.
I favor structuring the output folders based on content_url values of server/site/workbook/view , as this would maintain uniqueness across each server, be more human-readable, and allow for more flexible comparison scenarios. If there's a good reason to continue allowing the LUID-based structure, perhaps this could be implemented as a command-line option.
The current output folders generated by TabCompare are based on LUID values returned from the REST API. These are great for ensuring uniqueness, but are not easily read or used by humans trying to follow up on specific image differences they've found. Additionally, if the two servers are not based on the exact same backup file--say someone wanted to do comparisons based on content they copied over via the Content Migration Tool--then the image comparisons cannot be done, because the LUIDs between servers will not match.
I favor structuring the output folders based on content_url values of server/site/workbook/view , as this would maintain uniqueness across each server, be more human-readable, and allow for more flexible comparison scenarios. If there's a good reason to continue allowing the LUID-based structure, perhaps this could be implemented as a command-line option.