Hallo zusammen, ich bin gerade an einem Projekt, das einen FPGA(altera) und einen µC auf einer Rechnerkarte erhaltet. Meine Frage ist, wie man die Versionen von beiden verwaltet? So habe ich mir vorgestellt: Quartus erzeugt mir Jic-File(Format: projectname.jic) für PROM-Speicher. Kann man ihm sagen, das er sowas wie projectname_versionX_Y.jic austomatisch erzeugen soll, wobei "versionX_Y" wird vorher als Makro definiert. vielen Dank im voraus und schönes WE an Euch alle :-) lg
Was hällst du z.B. von SVN, GIT, oder ähnlichem? Kannst du einfach deine Projekte (Sourcen und bin) ablegen und ggf. mit Tags Versehen (Auslieferung Kunde XX 13.03.2013). Für Windows z.B. http://tortoisesvn.net/ Nur so als Vorschlag, ist in der Informatik üblich solche Tools zu verwenden... mfg Andreas
Hallo Andreas, Danke für deine schnelle Antwort!:) Mir scheint sowas neu und ...kompliziert:( Kann man sowas in Quartus nicht erledigen lassen? Lg
Naja, besonders kompliziert ist das nicht. Aber man muss schon etwas Handarbeit anlegen, ganz von alleine können das die Tools nicht. Wir verwenden z.B. einen TeamCity Build Server, der vergibt automatisch Versionsnummern, die sich aus den SVN Versionen und der Build Nummer zusammen setzen. Die werden dann in ein VHDL File als Constant durch das Build Script geschrieben, und somit ist jede Version eindeutig zurückverfolgbar und auch wieder herstellbar. Lokal geht das natürlich wie oben schon geschrieben auch recht einfach mit z.B. den SVN Revisions. Irgendwo müssen die Versionsnummern ja herkommen, wenn du die manuell vergibst, kommst früher oder später Quatsch raus, weil man da immer mal Fehler macht. Und was bringen Versionsnummern, wenn man die Quellcode Stände dazu nicht hat?
Also was man machen kann ist die SVN-Revisions-Nummer automatisch in eine VHDL Datei einbinden lassen, somit kann man feststellen welche Version gerade verwendet wird
Andreas B. schrieb: > Was hällst du z.B. von SVN, GIT, oder ähnlichem? Bei prof. Produktion im 20 Mann Team macht das Sinn aber darunter? Meiner einer macht Unterverzeichnisse mit #1, #2 die bei Bedarf im Verzeichnisnamen kommentiert werden. Geht mit Tools wie Total Commander in Sekunden und sogar beim compilieren. Rollouts kommen in ein freeze Verzeichnis und da gibt es dann auch eine Versionsnummer.
Hm, naja, SVN, Git o.ä. ist aus meiner Sicht selbst für einen einzelnen Programmierer/FPGA-Designer sinnvoll. Weil man da einfach den kompletten Versionsüberblick behält. Das muss ja nicht besonders aufwendig gemacht sein. Im einfachsten Fall reicht ein file-Repository auf einem Netzlaufwerk.
Christian R. schrieb: > Im einfachsten Fall reicht ein file-Repository auf einem > Netzlaufwerk. Das ist m.E. gerade für Privatanwender eine Hürde, Netzlaufwerke mit SVN-Server sind in Privathaushalten nicht besonders verbreitet und seinen Quellcode mag nicht jeder einem SVN-Provider anvertrauen. Zwar kann man SVN auch local aufsetzen und betreiben, das ist aber nicht gerade selbst- erklärend. RCS ist da Neuling- und Single-User-freundlicher; mit Einschränkungen auch CVS. MfG,
Fpga Kuechle schrieb: > Christian R. schrieb: >> Im einfachsten Fall reicht ein file-Repository auf einem >> Netzlaufwerk. > > Das ist m.E. gerade für Privatanwender eine Hürde, Netzlaufwerke mit > SVN-Server sind in Privathaushalten nicht besonders verbreitet und > seinen Quellcode mag nicht jeder einem SVN-Provider anvertrauen. Zwar > kann man SVN auch local aufsetzen und betreiben, das ist aber nicht > gerade selbst- erklärend. RCS ist da Neuling- und > Single-User-freundlicher; mit Einschränkungen auch CVS. Mit dem oben schon erwähnten TortoiseSVN unter Windows ist es wirklich sehr einfach: rechtsclick in einem leeren Verzeichnis -> Create Repository Here.
Aloha, ich nutze git und SVN immer kombiniert, und zwar git fürs Tracken der Änderungen während der Entwicklung, SVN fürs Einfrieren/Release. Mit 'svnversion' kann man sich die Tags per Makefile beliebig in Sources ausgeben, oder die $Rev:$ Tags nutzen (Siehe dazu Stichwort 'svn:keywords' zur Aktivierung des Tagging). Bei git ist das Revisioning grundsätzlich anders und nicht wirklich mit fortlaufenden Versionnummern kompatibel, müsste man sich also das Tagging auch selber stricken. Die Dinos wie RCS und CVS würde ich nicht mehr empfehlen, die haben so einige Limitierungen und Probleme mit grossen Projekten. svn und git sind ansich ohne grosses Gefuddel aufzusetzen, so dass die Repositories auf lokalen Laufwerken liegen.
Lattice User schrieb: > Fpga Kuechle schrieb: >> Das ist m.E. gerade für Privatanwender eine Hürde, Netzlaufwerke mit >> SVN-Server sind in Privathaushalten nicht besonders verbreitet und >> seinen Quellcode mag nicht jeder einem SVN-Provider anvertrauen. Zwar >> kann man SVN auch local aufsetzen und betreiben, das ist aber nicht >> gerade selbst- erklärend. RCS ist da Neuling- und >> Single-User-freundlicher; mit Einschränkungen auch CVS. > > Mit dem oben schon erwähnten TortoiseSVN unter Windows ist es wirklich > sehr einfach: rechtsclick in einem leeren Verzeichnis -> Create > Repository Here. OK, hab ich grad ausprobiert. Es werden mehrere Verzeichnisse (hooks,locks,...) angelegt. Damit habe ich immer nocht nicht die Sourcen in Ihren verzeichnissen unter Versionskontrolle. Wie gehts weiter mit SVN local unter Windows?
Fitzebutze schrieb: > Aloha, > > ich nutze git und SVN immer kombiniert, und zwar git fürs Tracken der > Änderungen während der Entwicklung, SVN fürs Einfrieren/Release. > Mit 'svnversion' kann man sich die Tags per Makefile beliebig in Sources > ausgeben, oder die $Rev:$ Tags nutzen (Siehe dazu Stichwort > 'svn:keywords' zur Aktivierung des Tagging). Bei git ist das Revisioning > grundsätzlich anders und nicht wirklich mit fortlaufenden Versionnummern > kompatibel, müsste man sich also das Tagging auch selber stricken. > Die Dinos wie RCS und CVS würde ich nicht mehr empfehlen, die haben so > einige Limitierungen und Probleme mit grossen Projekten. > svn und git sind ansich ohne grosses Gefuddel aufzusetzen, so dass die > Repositories auf lokalen Laufwerken liegen. Der Fragesteller Django bemerkt oben das svn kompliziert ist, da hilft es m.E. nicht ihn mit Fachchinesisch wie Tags/TaggingAktivierung/$Rev:$/Einfireren/Release/Repositories ihn vom Gegenteil überzeugen zu wollen. RCS ist zwar limitiert aber kein behäbiger, schwer kontrollierbarer Dino. Für globale Teams die an x Modulen werkeln ist eben eine komplexer Struktur und verschiedene Prozesse (Freeze/RollOut/ConfigManagment) notwendig die im Einzelkämpfermodus die Versionsverwaltung unnötig aufblähen. Meines Erachtens liegt das problem am Aufsetzen des SVN etc an den eigenwilligen Begriffen die es erst mal zu klären gilt Und das jede Versionsverwaltung alles anders bennent und geringfügig anders umsetzt. Da heisst es mal Depot/Repository/VOB/sandbox oder trunk/main/baseline oder label/tag/etc. Dabei will man doch nur verschiedene versionen abspeichern, die Änderugen zwischen diesen sehen und ggf. auf eine ätere Version zurückspringen. MfG,
Das Entscheidende jeder Versionsverwaltung, Teamarbeit, Autoaktualisierung, Branching, Seitenentwicklung und Zusammenführung von Dokumenten ist Ordnung im Kopf und eine geeignete Strategie, an die sich alle halten. Mit welchem tool das passiert, ist eigentlich zweitrangig. Wenn ich mir ansehe, wie in deutschen Stuben gebastelt wird, ist jedes Versinostool nutzlos. Meistens dient es nur zum Archivieren.
Fpga Kuechle schrieb: > OK, hab ich grad ausprobiert. Es werden mehrere Verzeichnisse > (hooks,locks,...) angelegt. Damit habe ich immer nocht nicht die Sourcen > in Ihren verzeichnissen unter Versionskontrolle. Wie gehts weiter mit > SVN local unter Windows? Die versteckten Verzeichnisse interessieren erst mal nicht. Das was du jetzt hast, ist das Repository, quasi eine Datenbank. Jetzt kannst du da rechte Maustaste -> Tortoise -> Repo Browser machen und die Adresse aus dem Feld oben kopieren. Dann gehst du in deinen Quellcode-Ordner und machst rechte Maustaste -> SVN Checkout und dann die Adresse reinkopieren. Und schon steht der Ordner zunächst mal formell untere Versionskontrolle. Wenn du dann SVN Commit machst, werden alle Dateien (die man anhakt) erstmalig hinzugefügt und versioniert. Ab dann gehts einfach in dem Quellcode-Ordner immer mit Commit und Update.
Christian R. schrieb: > Jetzt kannst du da rechte Maustaste -> Tortoise -> Repo Browser machen > und die Adresse aus dem Feld oben kopieren. > > Dann gehst du in deinen Quellcode-Ordner und machst rechte Maustaste -> > SVN Checkout und dann die Adresse reinkopieren. Und schon steht der > Ordner zunächst mal formell untere Versionskontrolle. Wenn du dann SVN > Commit machst, werden alle Dateien (die man anhakt) erstmalig > hinzugefügt und versioniert. Ab dann gehts einfach in dem > Quellcode-Ordner immer mit Commit und Update. Machn wir nen Artikel fürs wiki draus? Mit Screenshots? Ich hab die deutchsprachige Schildkröte am Laufen, da heist das alles etwas anders.
Och, für sowas hab ich immer wenig Zeit....außerdem gibts da ganz sicher schon zig Anleitungen für im Netz...
Fpga Kuechle schrieb: > Machn wir nen Artikel fürs wiki draus? Mit Screenshots? Ich hab die > > deutchsprachige Schildkröte am Laufen, da heist das alles etwas anders. fände ich begrüssenswert gfs könnte ich da sogar mitwirken meine Kenntnisse sind allerdings begrenzt
wir setzten hier anstelle von SVN Mercurial an. Für Windows findest Du es als TortiseHG, es gehört zu den dezentralen Versionsverwaltungen und eignet sich auch gut als Einzelentwickler. Ist meiner Meinung nicht so kompliziert wie SVN, aber das ist immer Geschmackssache. Wichtig ist jedoch immer, dass auch regelmäßig die Versionsstände gespeichert werden. Evtl. innerhalb von Branches.
Einfache Lösung ohne Tools: 1. Im Code hat man eine Versionsinformation, die man im System auslesen kann (z.B. beim µC über RS232). Diese Versionsinfo sollte ausführlich genug sein, um die einzelnen Entwicklungszwischenschritte anzuzeigen (also nicht nur "1.0" sondern z.B. "1.0.1223" für den 1223 Entwicklungsschritt). 2. Wenn Du mit einem Entwicklungsschritt zufrieden bist, kopierst Du das ganze Projektverzeichnis und erweiterst den Namen um die Versionsinfo (z.B. "MeinProjekt_1.0.1223"). Darin änderst Du dann nie mehr irgendetwas!!! Mit der Zeit bekommst Du dann jede Menge Verzeichnisse, was aber dank großer HD heute kein Problem ist. (Hier hilft auch ZIP) 3. Wenn Du Deinen aktuelles Projektstand mit einen alten vergleichen willst, kannst Du einfach die Projektverzeichnisse per "WinMerge" vergleichen. Mit einer Versionsverwaltung wie ClearCase geht das alles viel besser, aber ist halt auch etwas aufwändiger.
Kopfschüttel... Bronco schrieb: > 1. > 2. > 3. Das ist echt ein Haufen Handarbeit und genau dafür lassen sich (ohne Wertung) svn, git und mercurial super einsetzen. Einmal ein passendes Tutorial durchgeackert und man braucht kein manuelles Kopieren und hochzählen. Ist viel zu umständlich... Duke
Duke Scarring schrieb: > Das ist echt ein Haufen Handarbeit und genau dafür lassen sich (ohne > Wertung) svn, git und mercurial super einsetzen. Einmal ein passendes > Tutorial durchgeackert und man braucht kein manuelles Kopieren und > hochzählen. Ist viel zu umständlich... Keine Frage! Wahrscheinlich muß jeder für sich selbst die Erfahrung machen, wie toll ein Versionierungssystem ist, wenn man's mal verstanden hat. Allerdings ist meiner Meinung nach alles besser als Chaos... ;)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.