On 06/17/2014 01:45 AM, Julian Gonggrijp wrote:
Andrey Semashev wrote:
Thinking about it more, the requirement to build the dependency graph before the the download may require the cache to be available for any given git commit. This is probably a good reason to make the cache version controlled.
Perhaps it could be stored in a git note [1].
I'm not very familiar with git and don't know anything about git notes. Maybe they fit for this purpose. But my request would be that these notes are not required to be added by maintainers.
[...]
A slightly more advanced solution would be to have the handler download only the dependency file associated with the release tag using git archive [2], before cloning the entire module (that might not work with git notes, though). For releases, the dependency information could also simply be aggregated in the superproject archive.
Ok. As I said, I specifically did not require any particular means for delivering metadata into the tool. If this is possible with git, provided that usability is satisfactory, I'm all for it.
[...]
I agree that the cache is a good idea, as long as it's just a cache. I'm just saying that its role is auxiliary and it should not be managed by developers. [...]
So how about this: we work with two files. For now, let's call them conditional_deps.txt and deps_cache.txt. Both are optional and versioned if present.
A word of caution. I know very well the temptation to check in derived data, but I also know the pitfalls. It is not worth the risk. Find some other way to store and access the cache. The wrong version of the derived data will end up in commits, and you lose. Most people have an Internet connection, could the cache lookup be based on git commit sha1, and fetch the cache from some known base URL on the web? -- Bjørn