Man sollte nicht die Technik anpreisen, sondern die Lösung. Schreib doch mal auf, wieviele und welche Probleme es gibt und wie lange es jeweils braucht, so ein Problem im Durchschnitt zu lösen (
SVN Konflikte, Mergekonflikte, Buildbreaks). Dann kannst du immernoch deine Lösung präsentieren in welcher Form (
SVN) auch immer. Aber bedenke, dass Werkzeuge alleine keine Lösung sind. Dazu gehören immer auch Prozesse und letztendlich Menschen. Mitarbeiter müssen überzeugt werden (wenn auch von oben), dass dies auch sinnvoll ist, sonst rennt man gegen geschlossene Türen. Welche Prozesse/Vorgehensmodelle nutzt ihr überhaupt? Wasserfallmodell? Extreme Programming? Gibt es einen Ablauf für ein Fix-Commit-Test Zyklus? Wie wird getestet? uvm.
Letztendlich wird es DIE Lösung wohl garnicht geben. Es ist daher immer sehr sinnvoll die derzeitigen Strukturen und Abläufe in der Firma zu analysieren und darauf aufzubauen oder sie anzupassen. Grundlegend alles zu ändern ist sehr schwierig und kann auch nach hinten losgehen. Kleine Veränderungen, die gut propagiert werden helfen da oft vielmehr, besonders wenn die Leute begeistert mitmachen.
Weiterführende Literatur (habe ich auch):
Software Engineering, Jochen Ludewig et al., dpunkt.verlag
Lehrbuch der Softwaretechnik, Helmut Balzert, Spektrum
Abenteuer Software Qualität, Kurt Schneider, dpunkt.verlag
Managment von Softwareprojekten, Andreas Henrich, Oldenbourg