In den Tagen vor einer Veröffentlichung möchten wir möglicherweise verhindern können, dass Entwickler Dateien in den SubVersion-Zweig übertragen, es sei denn, ein Teamleiter hat die Änderungen überprüft und genehmigt (in diesem Fall würden sie eine temporäre Änderung vornehmen, um dies zu ermöglichen) ).
Bisher haben wir ClearCase verwendet, bei dem dies relativ einfach war.
Da der Befehl svn: lock nur pro Datei funktioniert, sind wir unsicher, ob wir dieses Verhalten in SubVersion emulieren können.
Was machst du?
Sie können sich GUI svn Clients ansehen, die normalerweise eine reichere Schnittstelle / Funktionalität haben als eine Befehlszeile. Zum Beispiel verwende ich TortoiseSVN mit den Optionen Sperre abrufen / Sperre aufheben , um alle Dateien im ausgewählten Ordner rekursiv zu sperren. BTW, es hat auch bequeme Möglichkeit, Tag / Branch zu machen und es als eine Aktion zu schalten.
Seitlich denken - warum nicht einfach einen Zweig an dem Punkt erstellen, an dem Sie ihn "sperren" wollen und nur diese Revisionsnummer in Ihrem Build / Release-Prozess auschecken.
Dann können sich Entwickler noch beim Stamm anmelden (oder an jedem anderen Zweig, an dem sie arbeiten) und wenn ein Teamleiter Änderungen für das Release genehmigt, können sie in den Zweig integriert werden. Zugegeben, das "sperrt" den Release Branch nicht wirklich, aber zumindest kann man Änderungen leicht nachverfolgen / rückgängig machen, wenn es nötig ist, und es verhindert nicht, dass Leute arbeiten. Die Quelle der Entwickler wird immer noch auf die Zweigstelle verweisen, an der sie gearbeitet haben, anstatt auf die neue Zweigstelle.
Erstellen von Verzweigungen ist sehr billig und einfach in SVN (glaube ich).
Was wir tun ist, den Zweig zu einem Tag zu verschieben und nur Lesezugriff auf das Tag zu haben.
Tags und Links svn branch release-management