| Thread Previous • Date Previous • Date Next • Thread Next |
On 25/11/17 02:14, Wayne Stambaugh wrote:
This is *the* fatal flaw with the cache library. User's assume it is stale symbols or a temporary copy. It is not. It is a snapshot of the current library symbols linked to the symbols in the schematic. It gets refreshed every time the schematic is saved. Once you delete this file or keep an out of date copy using cvs, all bets are off. It is only a matter of time before one of your symbol libraries changes or gets removed and you will end up with a broken schematic. The rescue code depends on the cache being up to date in order preserve you schematic. If the cache is not current, the rescuing cannot be guaranteed.
I don't think it's necessarily a flaw. And your description above is indeed a cache. That's not a bad thing. I recall that I left it out of version control because I wanted to make sure fixes to my symbols were always propagated to the design. In the repo I'm referencing for this discussion I had 10 project files all using the same local library. I didn't want to have to manually update each schematic to propagate changes. Deleting untracked files was what I did instead. At the time no one was making breaking changes to system installed symbols, so the system libs were stable for this workflow.
I'm trying think of the least effort way to migrate an old design in these circumstances.
Can we have the rescue code fail if no cache file is found? That at least lets the user know they are in uncharted territory. Then if a lot of users come complaining you will know if it is worth doing a bit more in the rescue code.
If the cache is not available during rescue you can load a copy of the libraries that were current at the schematic save date and either re-cache them or rescue them directly. But this is only worth doing if a significant number of users are affected.
| Thread Previous • Date Previous • Date Next • Thread Next |
