SVN Entwicklung zu zweit

[TurboMagic]

Hallo,

in mein Projekt ist jetzt noch jemand mit eingestiegen und wir verwenden zur Versionsverwaltung
SVN (nein, wir wollen nicht nach Git umsteigen).

Nun haben wir beim Mergen aber immer wieder viele unserer Meinung nach unnötiger Konflikte die
das mergen unproduktiv machen. Gibt's da irgendwelche nützlichen Hinweise für uns?

Hier eine detailliertere Beschreibung unseres Tuns:

1. wir haben einen Trunk

2. wir haben unter Branches jeweils einen eigenen Ordner

3. Jeder entwickelt fleißig vor sich hin und überträgt seinen Stand in seinen Ordner,
außerdem besitzt jeder auch eine Arbeitskopie des Trunks.

4. Ab und zu führt jeder den Stand des trunks aus dem Projektarchiv mit seiner
Arbeitskopie des Ordners aus dem Branch zusammen.

5. Danach wird der eigene Branch wieder übertragen.

6. Nun wird der eigene Branch aus dem Projektarchiv mit der Arbeitskopie des Trunks
zusammengeführt und danach dieser Stand in den Trunk übertragen.

Leider bekomme wir häufig Baumkonflikte einer Art, die nicht im Tortoise SVN Handbuch
beschrieben sind. Zum Beispiel in einer pas Datei, die mein Kollege gar nicht geändert
hat und in der ich ein paar auskommentierte Zeilen hinzugefügt habe. Und unserer
Meinung nach auch zuviele normale Konflikte.

Projektumfang ist schon > 200 KLoc.

Auch frage ich mich, welche Dateitypen in Delphi Projekten noch so alles sinnvoll
von SVN zu ignorieren wären.

Ich denke wir sollten .identcache und .local mit aufnehmen, richtig?
Sonst noch etwas?

Grüße
TurboMagic

[Lemmy]

und warum arbeitet ihr nicht gleich direkt in den trunk?

Eigenltich wäre das Vorgehen doch eher:

alle arbeiten mit und in dem trunk. Ein, zwei Wochen vor Auslieferung einer Version wird ein Branch angelegt, dort werden nur noch Fehler gefixt. Änderungen werden dann per Merge in den trunk übernommen. Damit ist sicher gestellt, dass auftretende Konflikte schnell gelöst werden können, weil jede kleine Änderung gemerged wird.Und im Trunk wird dann weiter geabreitet (d.h. neue Features entwickelt).

[TurboMagic]

Die Idee war, in den branches etwas unabhängiger arbeiten zu können, damit nicht jeder mit
jeder kleinen Änderung, die vielleicht noch gar nicht ganz durchdacht ist, gleich den anderen
beim nächsten Checkin stört.

[jaenicke]

Zitat von TurboMagic:

(nein, wir wollen nicht nach Git umsteigen).

Nun haben wir beim Mergen aber immer wieder viele unserer Meinung nach unnötiger Konflikte die
das mergen unproduktiv machen. Gibt's da irgendwelche nützlichen Hinweise für uns?

Leider ist aber Git genau die Lösung für derlei Probleme. Wir hatten bei unseren SVN Repositorys vorher auch solche Probleme nachdem wir von CVS dorthin umgestiegen waren.
Branchen und Mergen ist bei SVN echt eine Qual, was aber schlicht an der technischen Umsetzung liegt. Sprich wirklich schön geht es dort einfach nicht.

Seit wir Git nutzen haben wir noch viel mehr Merges, aber deutlich weniger Konflikte und weniger Probleme beim Lösen der Konflikte. Mittlerweile haben wir mit dem Ablauf keinerlei Probleme mehr.

Zitat von TurboMagic:

Die Idee war, in den branches etwas unabhängiger arbeiten zu können, damit nicht jeder mit
jeder kleinen Änderung, die vielleicht noch gar nicht ganz durchdacht ist, gleich den anderen
beim nächsten Checkin stört.

Die Idee ist auch vom Prinzip her gut, aber mit SVN einfach nicht gut umsetzbar.
Bei Git kannst du einfach lokale Branches anlegen und dazwischen wechseln und dann die Änderungen lokal und dann zum Server mergen. Du wirfst also nicht bei jedem Commit gleich alles auf den Server...

Deine Beschreibung eures Ablaufs beschreibt im Grunde sehr gut eine mögliche Arbeitsweise mit Git. Aber eben nicht mit SVN...

Zitat von TurboMagic:

Leider bekomme wir häufig Baumkonflikte einer Art, die nicht im Tortoise SVN Handbuch
beschrieben sind. Zum Beispiel in einer pas Datei, die mein Kollege gar nicht geändert
hat und in der ich ein paar auskommentierte Zeilen hinzugefügt habe. Und unserer
Meinung nach auch zuviele normale Konflikte.

Das liegt an der Art und Weise wie SVN intern Branches behandelt. Reduzieren kann man das Problem indem man strikt nur in eine Richtung Merges durchführt und nie in die andere. Das lässt sich bei eurer Arbeitsweise aber vielleicht kaum realisieren.

[hoika]

Hallo,

Zitat:

Zum Beispiel in einer pas Datei, die mein Kollege gar nicht geändert
hat und in der ich ein paar auskommentierte Zeilen hinzugefügt habe.

Das kann ich nicht glauben ...

Wir arbeiten auch mit SVN, Tree-Konflikte sind aber selten,
auch weil wir wenig neue Dateien haben, und fast keiner an der gleichen Datei arbeitet.

[Lemmy]

Zitat von hoika:

Hallo,

Zitat:

Zum Beispiel in einer pas Datei, die mein Kollege gar nicht geändert
hat und in der ich ein paar auskommentierte Zeilen hinzugefügt habe.

Das kann ich nicht glauben ...

dann mach mal einen Branch und arbeite da ne zeitlang, dann holst Du die Änderung aus dem Trunk in deinen Branch und anschließend die Änderungn deines Branches in den trunk.

[Lemmy]

Zitat von TurboMagic:

Die Idee war, in den branches etwas unabhängiger arbeiten zu können, damit nicht jeder mit
jeder kleinen Änderung, die vielleicht noch gar nicht ganz durchdacht ist, gleich den anderen
beim nächsten Checkin stört.

Dann erzeugt dafür Feature-Branches. Aber keine Branches die Monatelang laufen. ALso Branch anlegen, Feature entwickeln und wenn es so weit "fertig" ist, die Änderungen in den Trunk übernehmen (und nicht erst die Änderungen aus dem trunk in den Branch holen!). Damit sollten die Probleme geringer werden - allerdings würde ich für so was schon auch eher git oder Mercurial (weniger Erfahrung) empfehlen, weil ich bzgl. mergen mit svn auch schon sehr schlechte Erfahrungen gesammelt habe..

[Der schöne Günther]

Zitat von Lemmy:

allerdings würde ich für so was schon auch eher git oder Mercurial (weniger Erfahrung) empfehlen, weil ich bzgl. mergen mit svn auch schon sehr schlechte Erfahrungen gesammelt habe..

Zitat von jaenicke:

Leider ist aber Git genau die Lösung für derlei Probleme. [...]
Branchen und Mergen ist bei SVN echt eine Qual, was aber schlicht an der technischen Umsetzung liegt. Sprich wirklich schön geht es dort einfach nicht.

Kann ich auch nur unterschreiben. SVN wünsche ich mir wirklich nicht zurück, die Hälfte der Zeit immer mit Aufdröseln von Merge-Konflikten verbraucht, so wie du jetzt auch.

[Sherlock]

Den Industriestandard von vornherein auszuschließen ist Industriestandard

Machen würde ich es dennoch nicht. Versuchs doch einfach mal. Wenn sich git zu schwer anhört, ist Mercurial (hg) sicherlich auch ausreichend und einfacher zu bedienen. Aber SVN ist einfach nicht mehr Zeitgemäß und offenbart seine Schwächen in genau dem von Dir angestrebten Szenario.
Leider ist das von Joel Spolsky hervorragend geschriebene hginit.com nicht mehr online, aber dafür gibt es ja die Internet Zeitmaschine: http://web.archive.org/web/201809230...it.com/00.html

Sherlock

[DieDolly]

Zitat:

Versuchs doch einfach mal. Wenn sich git zu schwer anhört,

SmartGit verwenden. Das kann absolut jeder. Von GitKraken und purer Git-CLI rate ich ab. Für GitKraken braucht man einen Account und dann telefoniert das Programm auch ständig nach Hause und sendet Daten.

SmartGit macht nix davon und ist super einfach zu bedienen, da es nicht so eine völlig übertriebene Hauptsache-Cool-Oberfläche hat.