Benutzer Diskussion:Asklepios/SVN for the wild

Laserborg ist doch größer als ich dachte... Wenn gewünscht kann man den brainstormingkram größtenteils auslagern und nur relevanten kram (pcb daten) im svn belassen - Suschman 07:19, 4. Jul. 2009 (UTC)

im prinzip ist es gar nicht mal sooo schlimm binary blobs im svn zu haben - subversions delta angorithmus kommt auch mit BLOBs ganz gut klar. bei den größeren repos die wir für kundenprojekte haben @ fh haben wir unsere ganze doku (PDFs, Office & Co) auch immer im SVN, was gelegentlich mal mehrere 100mb grosse repos verbricht. Dadurch ist das aber immer an einem zentalen platz und versioniert. Wenn bei deinen sachen die versionierung nicht wichtig ist, und das nur aus convenience gründen im svn ist, dann mach dir doch einen ordner /user/suschman im SVN, dann stört's keinen ausser vegas festplatte! -- Hansinator 10:37, 4. Jul. 2009 (UTC)

ich denke auch, dass es kein Problem ist Dokumentation direkt bei dem Projekt zu haben. Das beinhaltet von meinem Verstaendnis her alles was irgendwie geschriebens beinhaltet. Videos und Sounds sollten sich eher auf ftp-servern / webservern liegen. Was bitte auch vermieden werden sollte, ist das einchecken von *.o Dateien. Allg. denke ich sachen die sich aus dem Code einfach funktional generieren lassen sollten sich nicht im SVN befinden, Sachen die sich schwer erzeugen oder schwer wiederfinden lassen sollten schon drinne lassen.
- mit --~~~~ kannst du eine signatur produzieren mit username + datum -- Hansinator 15:54, 4. Jul. 2009 (UTC)

ja, ich stimme dir da zu, aber doku muss nicht immer geschrieben sein! Es gibt da zum beispiel eagle oder ähnliche schaltpläne und layouts, 3d-modelle, sonstige diagramme und manchmal auch bilder. Je nachdem zu welchem grad man das selber gebaut hat oder ob man noch daran arbeitet, benötigen diese sachen vielleicht eine versionierung. Bei anderen ist es vllt. einfach nett, diese dabei zu haben, vllt. eine gezippte html doku zu der lib die man verwendet, in dem dir der lib, oder sowas. Oder man verwendet in seiner doku selber videos und bilder, das mag ja vorkommen. Was die projektverzeichnisse meiner meinung nach nicht sind, sind ein speicherort für sachen, damit man das immer bequem dabei hat. Für solche zwecke würde ich empfehlen jedem user ein eigenes scratch verzeichnis zu geben, das werden die meisten leute normalerweise nicht auschecken und da kann man gut unreifes zeug lagern. Dein punkt mit den generierten dateien ist auch gut, aber gehört irgendwie zu einem separaten topic als generische binaries die irgendeinen zweck erfüllen. Das man seinen generierten müll nicht in's svn steckt ist sowieso klar, hoffe ich zumindest... Sowas fällt unter die kategorie temporäre dateien, und wir sind kein cache :D Naja, wie dem auch sei
- ich denke man kann das gut aufteilen:
  - BLOBs die irgendwie zum dev-prozess des projektes passen und sinnvollerweise dabei sind
  - BLOBs die aus convenience gründen mit in das arbeitsverzeichnis eingecheckt wurden, aber dort eigentlich nix zu suchen haben (wie z.b. ganze programme oder videos die einem gefallen), wer sein persönliches arbeitsverzeichnis im svn haben will oder braucht, soll sich eben in /user/$name was machen, dann haben wir keinen ärger, dass wir das strikt verbieten, und haben das faktisch aus dem für laboranten & public interessanteren teil des SVNs raus
  - BLOBs die für massendownloads gedacht sind (vorkompilierte binaries oder zips, videos zu anschauungszwecken, und ähnliches). dafür gibt es zahlreiche andere lösungen, wie du schon sagtest.... FTP! Oder vielleicht auch youtube, flickr, whatever.
- -- Hansinator 16:10, 4. Jul. 2009 (UTC)
naja, muss man halt sehen, ich denke fuer jeden svn-user nen 'public-upload'-dir zu haben ist etwas gefaehrlich.
naja, die leute haben eh write zugriff auf's svn, entweder machen die sich selber so ein dir, oder sie laden ihr zeugs einfach irgendwo hoch.... dann müllen die anderen verzeichnisse zu. -- Hansinator 20:05, 4. Jul. 2009 (UTC)

hm, sag mal asklepios, hast du eigentlich vor die dependency probleme zu lösen? das sieht ja schonmal sehr spannend aus, dass du das alles aufschreibst! hast du auch gesehen, dass manche .c files include "../../lib/xy.c" machen? -- Hansinator 15:54, 4. Jul. 2009 (UTC)
"geloest" wuerde ich nicht sagen, da scheinbar einige sachen eher in den Bereich "-I/habe/ich/vergessen/ins/Makefile/zu/schreiben.h" fallen. Diese werde ich nicht fixen, weil ich dafuer genauer in den code schauen muesste, und glaub mir bei einigen sachen bekomme ich das kalte kotzen. mein Liebling ist im Moment '#include "../../../lib/can.h"' fuer sowas koennte ich leute einfach erschlagen. Was ich im Moment mache ist einfach sehen, welche Dirs noch benoetigt werden. Je weiter ich das droeseln kann mit den abhaengigkeiten, desto klarer stellt sich eine "general base" herraus, die man dann sauber machen kann um die Abhaengigkeiten zu vereinfachen. Wenn ich erstmal das src-atmel ding durch habe, sehe ich denke ich mal etwas klarer. Auch dass projekte die gcc-avr brauchen borg-base brauchen ist klar. Probleme macht nur wenn der gcc-std verwendet wird, der aber auch borg-base braucht. Das bekomme ich im moment noch nicht ganz sauber unter, aber wird sich ergebenAsk
naja, das funktioniert aber nur bedingt, nämlich bei den headern und nicht bei den *.c's... die .o's liegen dann in den lib verzeichnissen, das sollten sie aber nicht, da die libs mal für atmega8er oder 16er oder 32er kompiliert werden... wenn man dann das make clean vergisst, und das clean nicht auch so gebaut hat, dass es die include dirs mit beachtet, dann wird das problematisch. ausserdem muss man dann dem linker auch noch zusätzliche include dirs mitgeben. ich fand die lösung mit dem #include auch erst doof, ist aber das einfachste, wenn man nicht sein komplettes makefile neu schreiben will. -- Hansinator 20:05, 4. Jul. 2009 (UTC)
natürlich wäre es schön, wenn man ein makefile für z.b. den ganzen borg ordner hat, was dann mit make target das richtige target baut und alle subfolder richtig bedient. viele der borg unterordner sind eigentlich gar nicht nötig, der code ist redundant. -- Hansinator 20:05, 4. Jul. 2009 (UTC)
ich dachte dafuer sei borgconf resp borgware-2d zustaendig Ask
@Hansi, weist du wo momentan die aktuelle fimware für den andreborg herkommt, aus borgware-2d, andreborg, borg-16? In allen passiert hier und da mal ne Änderung, und das nicht konsistent bei ansich gleichen komponenten... --Suschman 14:33, 5. Jul. 2009 (UTC)