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

Re: gEDA-dev: SoC Hopeful




How do you envisage managing "versioning" of parts (if we decide to
bother at all)?

I admittedly hadn't  given much thought to it.  Since versioning doesn't seem to be something anyone does too heavily within the project, it could probably be  handled by the addition of a 'version' attribute to the specific parts database.  Something more robust would require either the implementation of a relational table between the specific part identification information (name, id#) and its attributes or a relation between the specific parts table as originally described and a table containing modifications to the original.  Either introduces a bit of complexity and I think in this case its probably better to go the simpler route.


...would this be something like a helper program to access
your parts database as:

gpartman --partid=AD12F397CD23 --type=gschem_symbol -o -

Yes, something along these lines is exactly what I had in mind. 


I think it is good to embed these symbols etc.. into the schematic by
defaulr - so the schematic can then be opened independently of the parts
manager, especially if the parts-manager fetches from an online
database. Most if not all the functionality to do this exist already.
(Anyhow.. a minor point).

I had considered this but decided against putting it in the writeup because I thought it would cause the problem of bloating in the schematic files.  If no one minds the slight increase it probably is better to do it this way; it ensures that we won't break anyone's schematics if we have to make changes to the hypothetical 'gpartman' down the way.


One train of thought I had was to have a .parts directory, which
contained the symbols / footprints instantiated from the database. SHA1
IDs (like git source code management uses) is great for making
file-names to hash-store these sorts of things.

Would this be something that would be done during build time to generate a full list (seems like it could get out of control), or would it simply be something to act like as a cache for whatever proejct the user's working on?

On a slightly off topic point: should I be asking around for potential mentors at this phase, or is that something which should wait until after the decisions on acceptances are made.


______________________________ _________________
geda-dev mailing list
geda-dev@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin
/mailman/listinfo/geda-dev


_______________________________________________
geda-dev mailing list
geda-dev@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev