Subversion und explizite Freigabe von Commits



  • Hallo zusammen! Wir haben in unserem Projekt in letzter Zeit vermehrt Probleme mit der Qualität des Codes (u. a. fehlende Überprüfungen, fehlerhafte Änderungen, wichtige Stellen wurden nicht kommentiert, etc.).

    Einen Teil der Fehler kann man mit Testfällen entdecken, aber leider bleiben einem für den Rest nur regelmäßige Code-Audits über. Nun haben wir uns die Frage gestellt ob es nicht möglich ist, dass Code erst dann ins SVN commited wird, wenn dieser von einer Dritten Instanz freigegeben wurde.

    Beispiel: Programmierer checkt ein, Auditor sieht die Commit Message und muss diesen Commit freigeben, bevor dieser tatsächlich im SVN landet und von anderen Programmierern wieder ausgecheckt werden kann.

    Ich hoffe ihr könnt meine Gedanken nachvollziehen und habt vielleicht sogar eine Lösung parat! 🙂



  • Wie wäre es mit Branches?



  • Wie wär's mit 'nem DVCS? Nur die Auditoren kriegen Schreibzugriff aufs zentrale Repository.



  • Branches oder Tags wären eine Möglichkeit.

    Revision-Properties wären eine andere.
    Revision-Properties sind Properties die auf einem Commit draufhängen, wie z.B. das Commit-Kommentar.
    Die sind so ziemlich das einzige in SVN was "mutable" ist, also nachträglich geändert werden kann.

    Setzen kann man die wohl mit svn propset --revprop -r <revision-nr> <propertyname> "<value>" (URL) .
    Und auslesen mit svn log (...) --with-revprop <propertyname> .

    http://svnbook.red-bean.com/en/1.2/svn.ref.svn.c.propset.html



  • Vielen Dank für eure Antworten, werden ich mir mal anschauen!

    @SG1: Ja, wir hatten auch überlegt Git einzusetzen. Hast Du schon Erfahrungen mit Git gesammelt?



  • Ja, aber nicht in dem Szenario. Kam mir nur so vor, als würd' sich das wunderbar anbieten.



  • git ist für genau so was bestens geeignet. nur bestimmte leute haben schreibzugriff aufs zentrale repository. andere erstellen einen eigenen clone und senden einen pull request, wenn die arbeit fertig ist. jemand mit schreibrechten guckt sich die arbeit an und wenn alles passt, merged er die änderungen ins zentrale repository.

    github ist hier übrigens extrem komfortabel. du kannst dort projekte forken, wenn du keine schreibrechte hast. von dort kann man dann direkt über die weboberfläche einen pull request anlegen. der pull request wird quasi als ticket im system angelegt und alle verantwortlichen benachrichtigt. man sieht alle commits und änderungen und ob es konflikte gibt. alle beteiligten können direkt über die oberfläche kommentieren, sogar bis auf codezeilen ebene. wenn alles ok ist, drückt man aufn knopf und die änderungen werden gemerged.

    als ergänzung könnt ihr auch erwägen, ein continous integration system zu benutzen, so dass automatisch beim commit bestimmte dinge geprüft werden (sind tests vorhanden, laufen die tests, bestimmte metriken wie checkstyle). ist aber kein hinreichendes kriterium für gute code qualität.


Anmelden zum Antworten