Background
For packages with long version histories, a significant amount of time can be spend building up the history of changes needed to perform the merge. It would be nice to be able to only do the work once for any given set of versions. Since Vesta already has a mechanism to cache function results, we would like to reuse that for version history information. Additionally, having that information available will make it much easier for VestaWeb to compute and show annotation information.
Cache Storage
(see HowCachingWorks for background info on how objects are stored in the cache)
We need to store this data in the cache in a way that will:
- prevent the evaluator from getting an accidental cache hit on it.
- only use dependency types that the evaluator understands.
This is one possible method of doing that, but it doesn't account yet for anything other than the most common cases.
Primary Key
For the PrimaryKey we can simply use the fingerprint of the path to the package.
Secondary Dependencies
In order to ensure #1 above, we'll first add a secondary dependency similar to !/vmerge/history = true. The evaluator currently only ever sets ! type dependencies with the value FALSE so it will never be able to hit.
We also need to record the list of versions incorporated in this history, and need to do so in a way that allows the tools to determine if an entry with a useful superset of versions already exists. This can be done by recording a dependency of type B (which the evaluator uses to mean "the set of names," so it seemed like a natural choice) with the path being a specially formatted string. This string will be formed by taking the paths of all the versions in this history, relative to the path used for the PK, and concatenating them together using ! as a delimiter. If a path should happen to have a ! in it already, it will be escaped with a second !.
Since all the useful information identifying the cache entry is recorded as a dependency path, it doesn't really matter what is stored as the value. Simply using TRUE should be sufficient.
Implementation Details
There's a few steps that need to happen before this will work. Some of them can be done in parallel, others are dependent on each other.
Port PreciseCodevilleMerge into C++ so that it can be wrapped with SWIG and available to languages other than python.
Audit the memory management in the cache client so that it will not leak memory in a non-garbage collected environment.
- SWIG both of the above libraries.