Mail Archives: geda-help/2012/10/16/04:12:20
John Doty:
> On Oct 14, 2012, at 2:27 PM, Benjamin Bergman wrote:
> > On Oct 13, 2012 12:50 PM, "Karl Hammar" <karl AT aspodata DOT se> wrote:
> > > Well you could possible use the md5sum of the sym file, what about:
> > > $ md5sum git/openhw/share/gschem/diode.sym
> > > cc2da042b5ea5afd65f4153bfff79b92 git/openhw/share/gschem/diode.sym
> > > And in the .sch file, this file is referenced by:
> > > C 18600 19900 1 0 0 diode.sym md5=cc2da042b5ea5afd65f4153bfff79b92
> > I think this is the way to go. This is essentially how all content
> > is tracked and referenced in git and adds a layer of corruption
> > detection, while costing very little in terms of resources or
> > infrastructure.
>
> Shudder. That assumes that symbols rarely change.
That is a false assumptions, and I have seen symbols dissapear from
the cvs also. But that doesn't hinder you to have a directory
structure like
ver1/diode.sym
ver2/diode.sym
ver3/diode.sym
and regardless of the order which thoose appear in the lib-browser,
a md5-tag could find the right diode.sym for you. And why not allow
a cvs-tag/git-commit-id to extract that old sym file from the
version handler?
> But a sensible way to use gEDA is to have project-local symbols
> that change as packaging or other part selection attributes change.
That is what works today, but that shouldn't hinder us to try out
other ideas.
///
It is nice to include the cvs sym's in the library browser, at
least to find what's out there. Currently one cannot use the second
or third of a duplicate sym (unless you copy or embed it); I think
it would be nice to solve that little problem.
///
Having a md5-thing as exemplified above could alert us when we have
forgotten to update our sch's when we made changes to the project
local sym's.
Regards,
/Karl Hammar
-----------------------------------------------------------------------
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57
- Raw text -