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
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.
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... ;)
