On Tue, 2011-05-24 at 00:41 -0700, Colin D Bennett wrote: > It might be useful to include a UUID in symbols so that once a > particular symbol is in use, the identity of that symbol can be > guaranteed through a UUID reference. Of course, > there would be backward-compatibility for symbols without a UUID > attribute, but if a schematic made use of a symbol with a UUID, then > the schematic is future-proofed against any future name collisions for > that symbol. In addition, a SHA1 hash (for example) would also ensure the tools can detect when a symbol has changed in the library - without requiring the person changing the symbol to update a version field. (An alternative would be an embedded copy of the original symbol to compare against). The embedding idea would actually work well to make schematics portable, but would lead to cluttered schematic files. If we were to move to a container based file format at any point, such copies would essentially be free (w.r.t. the level of disk space required). FWIW, I'm not a big fan of UUIDs, assigned, random or otherwise. As a silly idea - one could imagine a way of producing a "this symbol replaces..." field in an edited symbol which incorporates the SHA1 hash of the previous version. Perhaps the "this symbol replaces ...." field could also contain flags to specify whether the symbol is a direct compatible replacement, requires wiring changes, or whatever. The flags would define how complainy the tools got before the user acknowledged the change, e.g.: Silent change (using the new SHA1 when the user next saves the page) Informational warning Cautionary warning ...? The higher level warnings would cause gnetlist (and other tools) to abort processing unless the user can acknowledge the change. Basically I'm thinking along the lines of "git" revision control for symbols, or at least the log mechanism - even if the storage of previous versions isn't something we choose to do. A more complex (and not necessarily superior) solution than hashing the whole symbol file, would be to make a hash of just the "important" parts which affect functionality - e.g. pins and attributes. This would allow cosmetic changes not to flag the same degree of warning as functional changes. Best regards, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me)
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ geda-user mailing list geda-user@xxxxxxxxxxxxxx http://www.seul.org/cgi-bin/mailman/listinfo/geda-user