Next: Code Design Up: Developer's guide Previous: CVS-pathes and modules Contents Index
READ_ME der Database):
database-method-----testcase----------------------------------version
bsp:
database-DNS--------DNS_cyl_50x50x10_i_Re=10_s---------- ----v-01-12-06
| | | -v-02-03-11
| | | - ...
| |
| - DNS_cyl_50x50x10_i_Re=100_s-------------v-01-11-02
| |
| -... - ..
|
-LES ------LES.GERM_chan_100x100x300_i_Re=3900_p -v-02-02-22
| | ...
|
-RANS
- ...
Zum Aufbau der Test-Daten-Basis sollen die im folgenden kurz beschriebenen Skripte verwendet werden.
Vorgehen:
- Ausschecken des Moduls : cvs -d [username@]cvs[.fnb.maschinenbau.tu-darmstadt.de]:/home/fhpuser/tests checkout -d sandkastenname database
- Zum weiteren Arbeiten die vorhandenen Skripte benutzen!
Mit diesen Skripten wird die Verzeichnisstruktur aufgebaut
und diese in das cvs-Repository eingetragen. Die Skripte fangen
keine falschen Benutzerangaben ab
- Alle Files muessen in die entsprechenden Verzeichnisse kopiert werden. Sollte die Verzeichnisstruktur nicht ausreichen, bitte mail an mich.
Dateien die in das cvs-repository eingetragen werden sollen, muessen einen Punkt im Dateinamen enthalten!
- Das Gitter wird je testcase nur einmal eingetragen! Bitte auch die Directories references und comments fuellen.
Die Skripte sollten nur in den Verzeichnissen aufgerufen werden, in
denen sie lagern und nicht in den "utl" Verzeichnissen!
(shell: Achtung bei vielen shells (z.B. bash) ist das Verzeichnis ./ nicht standardmaessig in PATH ! Also aufruf mit ./name )
- Sollte fuer die gesuchte Methode noch kein Verzeichnis angelegt sein, so kann man utl/new_method dieses anlegen.
Reihenfolge der Aufrufe:
new_method -- Wird aufgerufen im Verzeichnis database_home mit new_method
Legt neues Verzeichnis an und kopiert die notwendigen Skripte an die entsprechenden Stellen.
new_test_case --erstellt eine Verzeichnisstruktur fuer einen Testfall.
Der Name wird aus den eingegebenen Strings zusammengesetzt.
Sinnvolle Abkuerzungen muss sich der Benutzer selbst ueberlegen.
Bei der Anzahl der Gitterpunkte halte ich es fuer sinnvoll,
die Gitterpunkte ueber alle Bloecke ungefaehr zusammenzurechnen.
Wenn besonderer Wert auf die Blockaufteilung gelegt wird schlage
ich folgendes vor: :10x10x10:20x20x20:10x20x10 usw fuer grid
einzutragen.
Der entstandene Name hat dann folgende Struktur:
Model_geometrie_grid_isotherm/temperature_Reynoldsnumber_paralles/seriell.
BSP: LES.GERM_chan_100x100x300_i_Re=3900_p.
In dem Verzeichnis wird das Gitter einmal in grid abgespeichert!
Fuer jede Version muss im Testfallverzeichnis das Skript
new_version -- aufgerufen werden.
new_version legt Versionsverzeichnisse an. Verwendet werden soll das
checkout-date von der benutzten FASTEST-Version!
!!! UND NICHTS ANDERES !!!
Nur so ist es m"oglich genau diese Version aus dem
repository wieder herzustellen!
In den entstandenen Unterverzeichnissen muessen dann die benoetigten Projektdateien abgelegt werden.
Danach werden mit store_[method/tcase/version] die neuen Eintraege an das Repository zurueckgegeben. Bitte immer diese Skripte zum zurueckschreiben verwenden, einzige Ausnahme: Spaetere Erweiterungen in den Verzeichnissen comments/references.
Aenderungen die spaeter in die references und comments eingetragen werden bitte von "Hand" mit cvs zurueckgeben. Achtung: Dateien die binaries enthalten bzw keinen Ascii-text bitte mit cvs add -kb file.name einfuegen. Dann werden Sonderzeichen kombinationen nicht als cvs-Schluesselwoerter behandelt!
Wenn eine Methode bzw ein testcase bereits vorhanden ist, kann man sich nur diese Verzeichnisse ausschecken und bearbeiten.
---------------------------------------------------------------------------
Die Skripte sind sicherlich nicht besonders elegant, stellen aber eine einheitliche Struktur sicher und uebernehmen ein wenig Arbeit mit dem CVS.
Sollten irgendwelche Probleme auftreten bitte mail an mich:
sternel@fnb.tu-darmstadt.de 15.11.2001