Chaos mit mehreren EAGLE Instanzen

Hans Lederer schrieb:

Oliver Betz schrieb:

Abgesehen davon: "Mitarbeiter im Fertigungsprozess" sollten keinen

Zugriff auf die Quellen haben.

 

 

Das ist m.E. ein Organisationsproblem. "Mitarbeiter im

Fertigungsprozess" erhalten kontrollierte Kopien (z.B. aus einem

Revisionskontrollsystem). Den Weg zu diesen Kopien vom Eagle Control

Panel abhängig zu machen, würde ich nicht verantworten wollen.

 

 

Und ich würde niemals 25 Leute ohne Kontrolle auf die Eagle-Projekte

zugreifen lassen (schauder).

 

 

Hmmm...  Schon richtig,  aber noch lang nicht jeder kleinere Betrieb hat

eine universelle Versionsverwaltung / Revisionskontrollsystem.

"kontrollierte Kopien für die Fertigung" sind auch durch einfaches

Kopieren der Dateien möglich und m.E. sinnvoll.

Geregelte Dateizugriffsrechte schon eher.  Mit lediglich Leserechten

oder einem Bearbeitungs-Passwort scheint mir das schon akzeptabel und

der kleinere Overhead.

Und dann beschwert sich der Adler, daß er die epf nicht schreiben

kann...

Es gibt ja noch andere Probleme beim Zugriff von verschiedenen

Arbeitsplätzen aus, z.B. die Bildschirmauflösung.

 

Oh ja.  Eagle sollte beim Öffnen die im EPF notierten Fenstergrößen auf

die aktuellen Bildschirmgrenzen limitieren.

Servus

Oliver

Oliver Betz schrieb:

Hans Lederer schrieb:

8. Der Eagle-Projektmanager sollte sich etwas mehr an den gewohnten

Explorer anlehnen.  Der Projektpfad soll nur ein anfängliches

Arbeitsverzeichnis sein,  man soll auch daraus hochsteigen können.  Der

Hauptnutzen gegenüber anderern Explorern liegt in der zusätzlich

angezeigten Description -- die sollte aber in die EPF hinein verlegt

werden;  und im Stöbern in den Bibliotheken / Design Rules.

 

Die Description muß schon in der betroffenen Datei bleiben. Sonst gibt

es verschiedene Probleme.

 

Nein,  Mißverständnis:  Jetzt arbeitet der Eagle-Projektmanager strikt

verzeichnisorientiert,  er nimmt an,  ein Verzeichnis = ein

Eagle-Projekt.  Daher kommt der meiste Ärger und wohl auch die saublöde

Restriktion auf den fixen Namen Eagle.EPF.  Und daher auch,  dass er die

Beschreibung für dieses Projekt als extra Textdatei mit dem fixen Namen

DESCRIPTION in das Verzeichnis schreibt.

Ich meine hier,  dass diese Projektbeschreibung keine extra Datei sein,

  sondern mit im EPF stehen soll,  eben damit keine Zuordnungsprobleme

entstehen.  Sie würde dann zB angezeigt,  wenn man im

Eagle-Projektmanager die EPF markiert (noch nicht öffnet).

Ich möchte,  dass nicht mehr die Verzeichnisse für ein Projekt relevant

sind,  sondern rein nur die EPFs.  Und dazu ist eine freie Pfad- und

Namenswahl sehr wichtig!

Das hätte auch andere nützliche Nebenwirkungen,  zB auf die lästigen

Ladezeiten des Eagle-Projektmanagers -- er bräuchte nicht mehr alle

Verzeichnisse auf enthaltene EPFs abzuklappern,  sondern einfach nur den

Baum an dem einen aktuellen Verzeichnis aufklappen und die dort

enthaltenen EPFs aufzulisten.

--

Grüße,  Hans

Hans Lederer schrieb:

 

Nein,  Mißverständnis:  Jetzt arbeitet der Eagle-Projektmanager strikt

verzeichnisorientiert,  er nimmt an,  ein Verzeichnis = ein

Eagle-Projekt.  Daher kommt der meiste Ärger und wohl auch die saublöde

Restriktion auf den fixen Namen Eagle.EPF.  Und daher auch,  dass er die

Beschreibung für dieses Projekt als extra Textdatei mit dem fixen Namen

DESCRIPTION in das Verzeichnis schreibt.

ah so, habe ich nie benutzt - da ich ja die "Projektverwaltung" nicht

benutze. Ich weiß, wo ich welches Verzeichnis finde.

Ich meine hier,  dass diese Projektbeschreibung keine extra Datei sein,

sondern mit im EPF stehen soll,  eben damit keine Zuordnungsprobleme

entstehen.  Sie würde dann zB angezeigt,  wenn man im

Eagle-Projektmanager die EPF markiert (noch nicht öffnet).

 

Ich möchte,  dass nicht mehr die Verzeichnisse für ein Projekt relevant

sind,  sondern rein nur die EPFs.  Und dazu ist eine freie Pfad- und

Namenswahl sehr wichtig!

 

Das hätte auch andere nützliche Nebenwirkungen,  zB auf die lästigen

Ladezeiten des Eagle-Projektmanagers -- er bräuchte nicht mehr alle

Verzeichnisse auf enthaltene EPFs abzuklappern,  sondern einfach nur den

Tut er bei meiner Methode nicht.

Servus

Oliver

Hallo,

möchte mich auch mal in die Diskussion einmischen...

Wir haben 30 Eagle Lizenzen und machen ca. 100 - 150 Platinen pro Jahr.

Auch wir haben Anfangs erhebliche Probleme mit der

Projektverwaltung/-Verfolgung gehabt und das Problem mit dem Subversion

Client TortoiseSVN gelöst. http://tortoisesvn.tigris.org/

Das Programm wurde von unserem Admin auf einem Server installiert und  nun

können alle berechtigen Entwickler problemlos auf die Projekte zugreifen.

Vorteile:

- kostenlos

- autom. Backups.

- über den internen Project-Manager werden sehr einfach Benutzer Rechte

vergeben (admin, nur lesen, lesen + schreiben)

- Projektdateine können gelockt werden, dadurch problemloses arbeiten mit

mehreren Leuten an einem Projekt möglich.

- alle alten Versionsstände können wieder hergestellt werden!

- es liegt immer die aktuelle Version auf dem Server.

- Unterprojekte in Projekten problemlos realisierbar.

- Projektverzeichnisse mit Unterverzeichnissen werden komplett vom Server

geladen. Die epf liegt "lokal" für jeden Benutzer individuell auf seinem

Rechner.

Nachteil:

- jedes Projekt muß von jedem Anwender erst einmal auf seinem Rechner lokal

eingerichtet werden.

- bedarf etwas Einarbeitungszeit, ist zuerst nicht ganz einfach zu

verstehen.

Keiner unsere Mitarbeiter möchte SVN mehr missen, ist ein super arbeiten und

ich denke für den einen oder anderen ganz interessant.

--

Lutz Plötner

"Lutz Ploetner" schrieb:

Auch wir haben Anfangs erhebliche Probleme mit der

Projektverwaltung/-Verfolgung gehabt und das Problem mit dem Subversion

Client TortoiseSVN gelöst. http://tortoisesvn.tigris.org/

Sehr gute Idee.

Nachteil:

- jedes Projekt muß von jedem Anwender erst einmal auf seinem Rechner lokal

eingerichtet werden.

- bedarf etwas Einarbeitungszeit, ist zuerst nicht ganz einfach zu

verstehen.

Das ist wahr, Einsteiger können schon durch die Terminologie

abgeschreckt werden.

Es ist aber nicht so schlimm, wenn man mit dem Neuling eine kleine

"geführte Tour" macht. Wer ein CAD-System bedienen kann, versteht auch

Subversion bzw. Tortoise sehr schnell.

Und es ist eine lohnende Investition!

Keiner unsere Mitarbeiter möchte SVN mehr missen, ist ein super arbeiten und

ich denke für den einen oder anderen ganz interessant.

Die normale Reaktion nach der Einführung einer Versionsverwaltung ist

regelmäßig "hätte ich das doch schon früher gemacht".

Jetzt fehlt noch eine ausgefeilte "Diff"-Methode für Eagle-Dateien.

Servus

Oliver

On 17.12.2009 15:42, Oliver Betz wrote:

...

Jetzt fehlt noch eine ausgefeilte "Diff"-Methode für Eagle-Dateien.

In der nächsten Version wird das Dateiformat auf XML umgestellt,

so daß "diffs" kein Problem mehr sein dürften.

Klaus Schmidinger

--

_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10

CadSoft Computer GmbH                   Fax:   +49-8635-6989-40

Pleidolfweg 15                          Email:   kls@cadsoft.de

D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de

_______________________________________________________________

Klaus Schmidinger schrieb:

Jetzt fehlt noch eine ausgefeilte "Diff"-Methode für Eagle-Dateien.

 

In der nächsten Version wird das Dateiformat auf XML umgestellt,

so daß "diffs" kein Problem mehr sein dürften.

ich erinnere mich an die Ankündigung. Hoffentlich bleibt es trotzdem

halbwegs kompakt. Manches XML ist ziemlich aufgebläht.

Und die Reihenfolge der Elemente sollte deterministisch sein, damit

kleine Änderungen am brd/sch nicht die ganze Datei

durcheinanderwürfeln.

Grüße,

Oliver

On 18.12.2009 15:12, Oliver Betz wrote:

Klaus Schmidinger schrieb:

 

Jetzt fehlt noch eine ausgefeilte "Diff"-Methode für Eagle-Dateien.

In der nächsten Version wird das Dateiformat auf XML umgestellt,

so daß "diffs" kein Problem mehr sein dürften.

 

ich erinnere mich an die Ankündigung. Hoffentlich bleibt es trotzdem

halbwegs kompakt. Manches XML ist ziemlich aufgebläht.

Na ja, die Dateien werden natürlich größer werden als bisher, denn wo

jetzt ein Durchmesser mit zwei Byte gespeichert ist, wird dann sowas

wie

  diameter=1000

stehen.

Und die Reihenfolge der Elemente sollte deterministisch sein, damit

kleine Änderungen am brd/sch nicht die ganze Datei

durcheinanderwürfeln.

Dafür werden Sorge tragen, indem wir bei der Ausgabe alles sortieren

(nach Namen bzw. Koordinaten oder was auch immer sich anbietet).

Eine Änderung soll auf jeden Fall nur einen lokalen "Diff" in der

Datei verursachen. Die Änderung eines Bauteilnamens kann dann allerdings

zur Folge haben, daß die Zeile für das Bauteil von einer Stelle an

eine ganz andere wandert. Gleiches gilt für ein Signal (das dann auch

noch sämtliche Wires etc. "mitnimmt"). Aber irgend einen Nachteil

wird es wohl immer geben...

Klaus Schmidinger

--

_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10

CadSoft Computer GmbH                   Fax:   +49-8635-6989-40

Pleidolfweg 15                          Email:   kls@cadsoft.de

D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de

_______________________________________________________________

Klaus Schmidinger wrote:

Na ja, die Dateien werden natürlich größer werden als bisher, denn wo

jetzt ein Durchmesser mit zwei Byte gespeichert ist, wird dann sowas

wie

Dem könnte man etwas beikommen indem man als Variante die Datei auch

komprimiert speichert. Ein Beispiel dafür wäre das neue MS Office Format

das auch gezipptes XML ist.

--

Arnold Hübsch

Arnold Huebsch schrieb am 19.12.2009 07:53:

(...) Ein Beispiel dafür wäre das neue MS Office Format

das auch gezipptes XML ist.

Also quasi das alte OpenOffice-Format. Wer hat's erfunden??

Gruß

Patrick