On Tue, Mar 11, 2014 at 6:18 AM, =E1=CC=C5=CB=D3=C5=CA =E8=C1=D2=D8= =CB=CF=D7=D3=CB=C9=CA <svetonomer AT gmail DOT com> wrote:

"The Pragmatic Programmer" was written= by two guys with lots of experience in real world firmware design. A lot o= f the book also applies to=9A Hardware design. One thing that they stress t= hrough out the book is to NEVER copy any data in your database.

Most commercial= programs for pcb design copy library components in the pro= ject files.

An organisation like gEDA=9A should keep all lib= raries under a revision control system that anyone can check out.

Users have the right<= /span> to keep their own components and not include them in any repository.
Not all users have Geda gedasymbols account due= to obvious reasons.

Then you can easily check for updates and = revisions.

And do it all<= /span> manually.
And if suddenly the up= dated components create bugs in the old schemas need to manually roll ba= ck, and then stored in directories with these old schemas. So you= come to my version.

A lot of design= ers do make copies of things all the time. A lot of commercial projects run= into problems.=9A Some designers have traced the root cause of these probl= ems back to somebody using the wrong copy of something. That is why we want= you to stop making copies, you are making our jobs harder.

Everybody MUST keep their components i= n a repository. We call that "keeping a backup". It does not have= to be on the internet and visible to the world. My personal backups are a = monthly dump to dvd and stored it in the barn in case the house burns down.= If you work for a company then you may=9A work on a local copy of your fil= es on your workstation but the "official" copy will be kept by th= e company in their repositories. You will make frequent (ie: weekly or even= daily) check ins so that your latest work is always stored in a repository= . That's how the pros do it.

Updating components do not break old d= esigns. Once a component is released and used in production then you cannot= make any material changes to that component. You can however create a new = revision of that component and release that one with a different version nu= mber. When a user does an update then they will see that there are new vers= ions and can decide to stay with the old or replace it with the new. Nothin= g breaks unless the user takes action. If something does break then they ca= n back out by deleting any changed file and restoring them from the reposit= ory.

Now during the early development=9A ph= ase before anything is released there is a chaotic period where everyone is= making changes without doing an official new versions and=9A things are br= eaking every day. You simply have to warn the other designers and hope it s= ettles down quickly.

Besides versions there is a concept ca= lled variants. In IC design you want to create components that are flexible= so the end user can customize them to their exact needs. We do this using = parameters. But parameters do not work in two cases, they cannot modify a p= ort list or a file list. These require variants.

If you have a cpu with the option of h= aving a debugger interface then you cannot select this with a parameter. Th= e debugger will have io ports that don't exist on a non-debugged cpu. S= o you will release two variants, one with debugger ports and one without.

John Eaton
=9A

=9A