See sillsdev/Mercurial4Chorus#33 (comment) for the full rationale behind this idea. Short version: this would unlock the ability to build Mercurial4Chorus in a different way which should lead to speedups in a Chorus Send/Receive process on Windows. (I noticed a speedup of 30-40% on my machine, but that was not carefully measured, and it was just running the Chorus tests. The actual speedups of Send/Receive would be lower, possibly just 5-10%, but should still be noticeable).
Longer version below.
Currently, the MakeWixForDirTree task looks for .guidsForInstaller.xml files as it puts together the file list for an installer; for every file it finds, it looks in the same directory for a .guidsForInstaller.xml file and gets the GUID from that file, for GUID stability between different versions. Each .guidsForInstaller.xml file only contains GUIDs for files in the same directory that it's in, not for an entire directory tree.
The change I want to make to the Mercurial4Chorus build process would create nearly a hundred directories under win/Mercurial, each one of which would need its own .guidsForInstaller.xml file. That's a maintainability nightmare going forward: if a future version of Mercurial renamed, say, its upgrade_utils directory to upgradeutils in the future, we would need to keep an upgrade_utils/.guidsForInstaller.xml file around, along with upgradeutils/.guidsForInstaller.xml, just to track the GUIDs of files that used to be part of the installer. If Mercurial ever were to significantly rearrange its directory tree, we could easily end up with both the old tree's directory structure (empty apart from our .guidsForInstaller.xml files) and the new tree structure (containing both Python files and new .guidsForInstaller.xml files) needing to be maintained forever in our Mercurial4Chorus repo.
To avoid that issue, I want to make one change to SIL.BuildTasks before diving into changing the Mercurial4Chorus build. Specifically, I want to allow it to consolidate existing .guidsForInstaller.xml files into a single one that can live at the root of a directory tree, and track GUIDs for all files in that entire tree.
Transitioning from a repo using the current system of one file per directory, to the new system, would be a three-step process:
- Run the new MakeWixForDirTree code with the ConsolidatedGuidFile property set; this will search out all the
.guidsForInstaller.xml files throughout the repo and consolidate them into one file at a location you choose, probably the root of the directory tree (i.e., win/Mercurial for the Mercurial4Chorus repo).
- Check in the new consolidated file.
- Delete the old
.guidsForInstaller.xml files scattered through the tree.
Note that steps 2 and 3 will be safe to do either in a single git commit, or in multiple commits: the code I'm planning to add will handle the scenario where a consolidated GUID file exists alongside leftover .guidsForInstaller.xml files. If a file ID exists in both and has the same GUID in both, that will be resolved, but if a file ID has a different GUID in two (or more) places, such as if a consolidated GUID file exists but a new .guidsForInstaller.xml file was accidentally generated by an older version of SIL.BuildTasks, the new code will log an error message, so that GUID conflicts like that can be detected and fixed.
Once SIL.BuildTasks is capable of running with a consolidated GUID file that tracks the entire directory tree, then I will be able to start work on the Mercurial4Chorus changes that I hope will end up improving Send/Receive speed on Windows by noticeable amounts.
See sillsdev/Mercurial4Chorus#33 (comment) for the full rationale behind this idea. Short version: this would unlock the ability to build Mercurial4Chorus in a different way which should lead to speedups in a Chorus Send/Receive process on Windows. (I noticed a speedup of 30-40% on my machine, but that was not carefully measured, and it was just running the Chorus tests. The actual speedups of Send/Receive would be lower, possibly just 5-10%, but should still be noticeable).
Longer version below.
Currently, the MakeWixForDirTree task looks for
.guidsForInstaller.xmlfiles as it puts together the file list for an installer; for every file it finds, it looks in the same directory for a.guidsForInstaller.xmlfile and gets the GUID from that file, for GUID stability between different versions. Each.guidsForInstaller.xmlfile only contains GUIDs for files in the same directory that it's in, not for an entire directory tree.The change I want to make to the Mercurial4Chorus build process would create nearly a hundred directories under
win/Mercurial, each one of which would need its own.guidsForInstaller.xmlfile. That's a maintainability nightmare going forward: if a future version of Mercurial renamed, say, itsupgrade_utilsdirectory toupgradeutilsin the future, we would need to keep anupgrade_utils/.guidsForInstaller.xmlfile around, along withupgradeutils/.guidsForInstaller.xml, just to track the GUIDs of files that used to be part of the installer. If Mercurial ever were to significantly rearrange its directory tree, we could easily end up with both the old tree's directory structure (empty apart from our.guidsForInstaller.xmlfiles) and the new tree structure (containing both Python files and new.guidsForInstaller.xmlfiles) needing to be maintained forever in our Mercurial4Chorus repo.To avoid that issue, I want to make one change to SIL.BuildTasks before diving into changing the Mercurial4Chorus build. Specifically, I want to allow it to consolidate existing
.guidsForInstaller.xmlfiles into a single one that can live at the root of a directory tree, and track GUIDs for all files in that entire tree.Transitioning from a repo using the current system of one file per directory, to the new system, would be a three-step process:
.guidsForInstaller.xmlfiles throughout the repo and consolidate them into one file at a location you choose, probably the root of the directory tree (i.e.,win/Mercurialfor the Mercurial4Chorus repo)..guidsForInstaller.xmlfiles scattered through the tree.Note that steps 2 and 3 will be safe to do either in a single git commit, or in multiple commits: the code I'm planning to add will handle the scenario where a consolidated GUID file exists alongside leftover
.guidsForInstaller.xmlfiles. If a file ID exists in both and has the same GUID in both, that will be resolved, but if a file ID has a different GUID in two (or more) places, such as if a consolidated GUID file exists but a new.guidsForInstaller.xmlfile was accidentally generated by an older version of SIL.BuildTasks, the new code will log an error message, so that GUID conflicts like that can be detected and fixed.Once SIL.BuildTasks is capable of running with a consolidated GUID file that tracks the entire directory tree, then I will be able to start work on the Mercurial4Chorus changes that I hope will end up improving Send/Receive speed on Windows by noticeable amounts.