sbp commented on issue #639: URL: https://github.com/apache/tooling-trusted-releases/issues/639#issuecomment-3879339592
The 3-way merge implementation will have some bearing on the attestable data. We need to compute the hashes of N anyway to write attestable data, and we can do this before acquiring the write lock. Those hashes might need to be updated if there are merge conflict resolutions. We can also read all of the hashes of B pre-emptively before acquiring the write lock. Although we could do this conditionally within the write lock itself, and although the condition is quite rare, we want to make the computation during the write lock as efficient as possible. To get the hashes of N, we need to compute them. But the hashes of B have already been computed and cached in the attestable JSON file. This file has two major sections: one of paths to hashes, which is what we need here, and one of hashes to other metadata, which accumulates between revisions and is never pruned. To make reading the information that we need more efficient, we should split this metadata into two separate files. We then only need to read the file containing the mapping of paths to hashes for B. If it turns out that there is a P revision, then we also need to read the mapping file for P, but that can only happen when the write lock is held because we cannot know what P is, or whether it even exists, until we obtain the write lock. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
