Subversion Richtlinien

Proggen.org - Lernprojekt: Duplikatefinder
Antworten
Benutzeravatar
fat-lobyte
Beiträge: 1398
Registriert: Sa Jul 05, 2008 12:23 pm
Wohnort: ::1
Kontaktdaten:

Subversion Richtlinien

Beitrag von fat-lobyte » Mi Aug 04, 2010 6:24 pm

Hallo.

Das Projekt hat sich für Subversion entschieden. Auch wenn das manchen (wie z.B. ich) nicht so ganz in den Kram passt, so sollten wir uns Dennoch alle darauf einstellen für längere Zeit damit zu Arbeiten.

Das Repository ist der Punkt, an dem der gesamte Code aller Entwickler zusammenkommt, und als solcher ist er automatisch eine Art "Gemeinschaftsraum".
Damit man in diesem "Gemeinschaftsraum" gut Arbeiten, sollte man wie in jeder Gemeinschaft gewisse Regeln befolgen.


Diese Regeln wurden bis jetzt noch nicht festgehalten. Ich habe mir ein paar Gedanken dazu gemacht, und mal einen Vorschlag dazu gemacht.
Selbstverständlich stehen die Punkt zur Diskussion, Fragen sind Willkommen.

Vielleicht könnte man auf dieser Basis ein gutes Richtlinien-Dokument erstellen, an das sich (in hoffentlich nicht allzu ferner Zukunft) alle halten werden.

Wenn jemand mit mir nicht Übereinstimmt, bitte erläutert welchen Punkt das Betrifft und warum,
Wenn ihr selber Punkte habt die euch am Herzen liegen oder wenn ihr für die Bestehenden Punkte weitere Gründe findet, dann ändert auch die Seite (eine kleine Notiz in diesem Thema wäre auch nicht verkehrt).


Hier der Link dazu: http://www.proggen.org/doku.php?id=proj ... upe:svnpol


Ich hoffe auf eine angeregte Diskussion.

mfg, fat-lobyte
Haters gonna hate, potatoes gonna potate.

Benutzeravatar
Bebu
Beiträge: 562
Registriert: Mi Okt 21, 2009 6:19 pm
Wohnort: In der Nähe von Salzburg - Bin aber kein Österreicher!

Re: Subversion Richtlinien

Beitrag von Bebu » Mi Aug 04, 2010 6:38 pm

Klingt so weit alles sehr vernünftig, nur bei den Commitkommentaren muss ich mich am Riemen reißen ;)
Wer immer nach dem Unerreichbaren jagt, der wird irgendwann auf die Schnauze fallen!

Benutzeravatar
Xin
nur zu Besuch hier
Beiträge: 8858
Registriert: Fr Jul 04, 2008 11:10 pm
Wohnort: /home/xin
Kontaktdaten:

Re: Subversion Richtlinien

Beitrag von Xin » So Aug 08, 2010 9:45 pm

Es beschreibt wie immer das Ideal. :-)

Deswegen sollte es auch so stehen bleiben.
Merke: Wer Ordnung hellt ist nicht zwangsläufig eine Leuchte.

Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.

Benutzeravatar
fat-lobyte
Beiträge: 1398
Registriert: Sa Jul 05, 2008 12:23 pm
Wohnort: ::1
Kontaktdaten:

Re: Subversion Richtlinien

Beitrag von fat-lobyte » Mo Aug 09, 2010 6:24 pm

Ich nehme an, die Richtlinien sind somit "beschlossen"? Soll ich den Hinweis dass es nur ein Vorschlag ist wegtun?
Haters gonna hate, potatoes gonna potate.

Benutzeravatar
Xin
nur zu Besuch hier
Beiträge: 8858
Registriert: Fr Jul 04, 2008 11:10 pm
Wohnort: /home/xin
Kontaktdaten:

Re: Subversion Richtlinien

Beitrag von Xin » Mo Aug 09, 2010 7:54 pm

fat-lobyte hat geschrieben:Ich nehme an, die Richtlinien sind somit "beschlossen"? Soll ich den Hinweis dass es nur ein Vorschlag ist wegtun?
Ich habe nichts dagegen und bisher hat sich auch niemand anderer dagegen ausgesprochen.

Von daher würde ich sagen... gelten sie als beschlossen, bis jemand was intelligentes dagegen vorzubringen hat.
Merke: Wer Ordnung hellt ist nicht zwangsläufig eine Leuchte.

Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.

Benutzeravatar
Kerli
Beiträge: 1456
Registriert: So Jul 06, 2008 10:17 am
Wohnort: Österreich
Kontaktdaten:

Re: Subversion Richtlinien

Beitrag von Kerli » Mo Aug 09, 2010 11:36 pm

Xin hat geschrieben:Es beschreibt wie immer das Ideal. :-)
Genau, jetzt müssen die Regeln nur mehr eingehalten werden ;)

Nur eine Kleinigkeit ist mir aufgefallen:
Wiki hat geschrieben:Tests (if any) durchgeführt werden.
Was macht denn das "(if any)" da? Sollten die Tests nicht vor dem eigentlichen Code kommen? :P
"Make it idiot-proof and someone will invent an even better idiot." (programmers wisdom)

OpenGL Tutorials und vieles mehr rund ums Programmieren: http://www.tomprogs.at

Benutzeravatar
Xin
nur zu Besuch hier
Beiträge: 8858
Registriert: Fr Jul 04, 2008 11:10 pm
Wohnort: /home/xin
Kontaktdaten:

Re: Subversion Richtlinien

Beitrag von Xin » Di Aug 10, 2010 10:19 am

Kerli hat geschrieben:
Xin hat geschrieben:Es beschreibt wie immer das Ideal. :-)
Genau, jetzt müssen die Regeln nur mehr eingehalten werden ;)
Ich sehe das frei nach Fluch der Karibik als Richtlinie. Danach sollte man sich richten und streben, aber Entwicklung findet in der Realität statt.
Und bevor ich eine Riesenaktion schiebe, um ja den Build nicht zu brechen, fliegt mir der Build eben um die Ohren und mit dem nächsten Checkin repariert.
Kerli hat geschrieben:Nur eine Kleinigkeit ist mir aufgefallen:
Wiki hat geschrieben:Tests (if any) durchgeführt werden.
Was macht denn das "(if any)" da? Sollten die Tests nicht vor dem eigentlichen Code kommen? :P
Machen wir Test-Driven-Development? (was meiner Erfahrung nach auch gerne mal mit Ansage an der Realität scheitert, insbesondere in dem Moment, wo eine GUI ins Spiel kommt.)
Merke: Wer Ordnung hellt ist nicht zwangsläufig eine Leuchte.

Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.

Benutzeravatar
fat-lobyte
Beiträge: 1398
Registriert: Sa Jul 05, 2008 12:23 pm
Wohnort: ::1
Kontaktdaten:

Re: Subversion Richtlinien

Beitrag von fat-lobyte » Di Aug 10, 2010 10:43 am

Kerli hat geschrieben:
Wiki hat geschrieben:Tests (if any) durchgeführt werden.
Was macht denn das "(if any)" da? Sollten die Tests nicht vor dem eigentlichen Code kommen? :P
Naja, wir haben noch keine wirklichen Tests, also wäre das ein bisschen verwirrend, wenn man Tests vorschreibt wenn keine da sind ;-)
Xin hat geschrieben: Machen wir Test-Driven-Development? (was meiner Erfahrung nach auch gerne mal mit Ansage an der Realität scheitert, insbesondere in dem Moment, wo eine GUI ins Spiel kommt.)
Ich sags mal so:
"Es wäre gut". Es ist ziemlich nützlich, um neu eingeführte Bugs aufzuspüren. Es hilft, sich an Interfaces zu halten. Es hilft beim portieren ("mach ich was kaputt wenn ich das ändere? ach egal, ich lass einfach mal die testsuite laufen."). Stichwort "Qualitätssicherung".
Dass das in der Realität nicht so ganz einfach ist, ist schon klar. Hashes zu überpüfen ist einfach: daten rein, daten raus, vergleichen obs die richtigen sind. Bei dem filesearch modul wirds schon etwas happiger. Muss man einen künstlichen Verzeichnisbaum anlegen? Wie testet man fehlende zugriffsrechte? Und das ganze auch noch portabel? Man bräuchte ein zwischenbibliothek, die würde aber gleich aussehen wie das filesearch modul selbst. Da muss man sich noch was überlegen.
Ich würde die Testbarkeit allerdings gerne als "Fernziel" dazunehmen.
Ich bin selbst nicht so der "Testmeister", hab außer einfachen difftests noch nie was in die Richtung gemacht. Aber das ist ja ein "Lernprojekt", und das ist eben auch etwas das ich gerne lernen würde.
Haters gonna hate, potatoes gonna potate.

Benutzeravatar
Xin
nur zu Besuch hier
Beiträge: 8858
Registriert: Fr Jul 04, 2008 11:10 pm
Wohnort: /home/xin
Kontaktdaten:

Re: Subversion Richtlinien

Beitrag von Xin » Di Aug 10, 2010 10:48 am

fat-lobyte hat geschrieben:"Es wäre gut". Es ist ziemlich nützlich, um neu eingeführte Bugs aufzuspüren. Es hilft, sich an Interfaces zu halten. Es hilft beim portieren ("mach ich was kaputt wenn ich das ändere? ach egal, ich lass einfach mal die testsuite laufen."). Stichwort "Qualitätssicherung".
Irrtum.

Nur weil die Tests funktionieren, heißt das nicht, dass man nichts kaputt gemacht hat.
Wenn das Stichwort QS lautet, dann reicht es nicht die Testsuite drüber zu jagen. Eine Testsuite ist niemals vollständig.
Eine Testsuite ist nur ein Indiz.
fat-lobyte hat geschrieben:Dass das in der Realität nicht so ganz einfach ist, ist schon klar. Hashes zu überpüfen ist einfach: daten rein, daten raus, vergleichen obs die richtigen sind. Bei dem filesearch modul wirds schon etwas happiger. Muss man einen künstlichen Verzeichnisbaum anlegen? Wie testet man fehlende zugriffsrechte? Und das ganze auch noch portabel? Man bräuchte ein zwischenbibliothek, die würde aber gleich aussehen wie das filesearch modul selbst. Da muss man sich noch was überlegen.
Ich würde die Testbarkeit allerdings gerne als "Fernziel" dazunehmen.
Tests sind kein Fernziel, die sind durchaus im näheren Bereich. Aber es stellt sich auch die Frage nach der Testbarkeit, insbesondere der automatischen Testbarkeit. Das Programm wird sich testen lassen, denn die GUI ist nur über ein Interface angebunden. Es lässt sich das ganze Programm über ein Mock-Objekt automatisch testen, das Benutzereingaben simuliert.
fat-lobyte hat geschrieben:Ich bin selbst nicht so der "Testmeister", hab außer einfachen difftests noch nie was in die Richtung gemacht. Aber das ist ja ein "Lernprojekt", und das ist eben auch etwas das ich gerne lernen würde.
Was hat es mit CTest auf sich? (Antwort ggfs. pls in den Test-Thread)
Merke: Wer Ordnung hellt ist nicht zwangsläufig eine Leuchte.

Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.

Antworten