Subversion: Löschen alter Feature-Zweige im Vergleich zu deren Beibehaltung

Question

Ich habe ein Subversion-Repository mit dem Standardlayout, also trunk/und branches/(und tags /). Wenn Sie an einer größeren Änderung arbeiten, wird ein Feature-Zweig verwendet, der regelmäßig mit dem Stamm synchronisiert und später wieder in den Stamm integriert wird (jetzt 1.5). Ziemlich normales Zeug.

Was ich frage mich ist, ob eine solche Feature-Zweig, einmal beendet und zusammengeführt sollte gehalten oder gelöscht werden. Das Subversionsbuch scheint gelegentlich darauf hinzuweisen, dass es üblich ist, sie zu löschen, aber ich habe auch eine Reihe von Open-Source-Projekten gesehen, die die Zweige behalten.

Ich bin auch etwas besorgt darüber, wie das Löschen einer Verzweigung es schwerer macht zu verfolgen, welche Zweige existierten, besonders wenn potentiell doppelte Namen in das Szenario eingehen (sagen wir zweimal suchen), ihre Commit-Historien verschwinden irgendwo in der Tiefe des Repositories etc.

Auf der anderen Seite werden Äste ziemlich oft verwendet, vor allem mit 1,5 jetzt, und ich mag den Gedanken, nicht durch eine große Liste von inaktiven Zweigen stochern zu müssen, um die I zu finden arbeite gerade an.

Was sind die Vor- und Nachteile, die ich vermisse? Was machen die Leute?

Answer 1

Wenn Sie wirklich besorgt sind, sie zu löschen, damit sie nicht vergessen werden, erstellen Sie einfach einen Ordner unter den Zweigen "inaktiv" und svn move Ihre älteren, inaktiven Zweige in diesen Ordner. Dies könnte das Beste aus beiden Welten für Sie sein.

Answer 2

Sie können sie sicher löschen. Wenn sie gelöscht werden, werden sie nicht aus dem Repository entfernt, der zugewiesene Speicherplatz wird nie zurückgewonnen, aber es sorgt dafür, dass Ihr gesamter Projektbaum aufgeräumter aussieht.

Answer 3

Ich habe Feature-Zweige gelöscht, wie wir fertig sind, wie ich den Mangel an Unordnung mag. Bei einigen anderen Entwicklern gab es leichte Verwirrung, aber da wir in unserem Fehlerverfolgungssystem Revisionsnummern von Commits aufgezeichnet haben, war das ziemlich reibungslos. Wenn jemand sagt, dass er keinen Zweig finden kann, ist der Hinweis, das Flag -rrevision auf seinem Log/diff/checkout/was auch immer zu verwenden, im Allgemeinen alles, was benötigt wird.

Answer 4

Mein Team löscht sie, um die Unordnung zu vermeiden. Es ist nicht so, als ob die weggehen. Sie können bei Bedarf abgerufen werden. Sie haben Recht, dass es schwierig sein kann, sie wieder zu finden: Sie müssen eine Revisionsnummer kennen, in der der Zweig existiert, also sagen Sie Ihrem Kunden, dass er sich diese Revision ansehen soll, um Ihre Dateien zu sehen.

Wir verwenden FogBugz für unser Projektmanagement, das verfolgt, wenn Dinge nach Revisionsnummer in unserem SVN-Repository begangen wurden. Wir können dies verwenden, um zu bestimmen, auf welche Revision wir zurückkommen müssen, um unsere Dateien zu sehen: Wir finden die Merkmalshistorie in FogBugz, schauen, um festzustellen, welche Revisionen der Zweig existierte, und verwenden diese Information, um rückwärts zu springen.