> Assume you have a symbol which was included in many your schemas from = CVS.
> Example capacitor or other usable for you.
> Througth time autor change pin length and make this less.
> All schemas in you archive is broken.

You can solve this example noting the version you used and include it=
somewhere so people can exstract the same version from cvs. A checksum
could be provided as an extra check.

What solve?

Symbol already changed.

Checksum wrong. Yes.

What gschem must do? Message report? Or CVS roll back? Or contact au= tor?

> > 2. When there exist different sources with the same name. For thi= s case
> > you can insert more data into the symbol, i.e. authors name and v= ersion
> > number.
> >
> That is, all versions must be kept, even when they are outdated.... > That is, project developers must have a centralized repository of
> characters.

You don't need a "centralized" repository, you need som= e kind of
version control, and it is a good investment to use one.=A0

All developers in his computers should have identical symbols (copies) an= d version control, even if not editing, simple view.

For = this they need to use=A0 many third-party tools for to ensure reliability his work,= instead simple use of Schematic editor.

Not all engineers want it.

Many want to be sure that they can always open and se= e his scheme, which they did years ago, when they need it, istead to make= = body movements with= version control program and others to eliminate unexpected bugs.

It is c= ertainly possible to embed = all symbols in his scheme, but = why keep the scheme in many of the sa= me characters, if you can keep = one as I propose to do.<= /span>
I do not really understand why we need these EMBEDDED characters in the form in which they exist.
They only complicate the syntax of sch-file and compli= cate scripts writing. EMBEDDED [ ] and etc. =

Check if you have a disk related problem, are your file currupt,
contact the author of the symbol, etc.

=A0And the author <= span class=3D"">will respond to you=A0through a month. Surely... :)

A checksum is a check that "all are in order". The procedure to h= andle
any mismatch is not solved by using a checksum, but it helps to _detect_ possible problems.

That's understa= ndable.
Followed by curses and body movements.

So your case for the "in the file library" solution is:

1, solve same name problem
2, get some reliability against sym file changes

And make this without manual activity.

3, and distribution=

Am I right?

Yes.

1 and 2 could be solved by including author/vendor and version
information.

Not solve. Only detect.

3 can be solved by making the your repo. public or by having some
"collect and distribute" script.

Yes. It may= be.

But all this is more difficult then 30-50 rows of C= code for change libgeda.

Also minus is that all these solutions are distributed.
There are thousands of scripts to<= /span> make any changes to the schema file.
Only refdesrenum-like scripts are about 10, maybe 100.<= /span>
But there is no one place where col= lected their descriptions.<= /span>

Although this is the = main function of the progra= m and shold be performed with gschem.

User,= especially the new user, <= span class=3D"">confused and repelled by this approach.

And yes, implementing thoose things, so your solution have a head
start, but others can catch up. The most interesting thing right now
is to identify problem areas of gschem sym file handling, proposing
different solutions, and sharing experiences. Implementation comes
later. You have a solution and an implementation, and that is a
very good starting point when trying to nail down a problem and
for discussions.

I agree completely.

<= br>

--e89a8ff1c01cff3a7504f4572579--