Benutzer Diskussion:Asklepios/SVN for the wild: Unterschied zwischen den Versionen

Aus LaborWiki
Wechseln zu: Navigation, Suche
Keine Bearbeitungszusammenfassung
Keine Bearbeitungszusammenfassung
Zeile 5: Zeile 5:
* 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.
* 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 --<nowiki>~~~~</nowiki> kannst du eine signatur produzieren mit username + datum -- [[Benutzer:Hansinator|Hansinator]] 15:54, 4. Jul. 2009 (UTC)
** mit --<nowiki>~~~~</nowiki> kannst du eine signatur produzieren mit username + datum -- [[Benutzer:Hansinator|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.




* 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? -- [[Benutzer:Hansinator|Hansinator]] 15:54, 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? -- [[Benutzer:Hansinator|Hansinator]] 15:54, 4. Jul. 2009 (UTC)

Version vom 4. Juli 2009, 17:06 Uhr

  • 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.


  • 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)