[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

gEDA-user: Handling symbol change [WAS: Re: cvs.gedasymbols.org and gschem]

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

Best regards,

Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,

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