Hallo,
ich pflege Bugfixes zum aktuellen - stable - Projekt in einem Bugfix-Branch. Ist eine solcher Bugfix erfolgt, wird ein neues Tag vom Bugfix-Branch erstellt. Mittels svn switch schalte ich dann in der Live-Umgebung auf den neuen Tag.
Soweit gedacht ...
Schnelle den neuen Tag noch auf einer Testmaschine geswitcht, um wirklich sicherzugehen und siehe da:
Eine Konfigdatei wird mir beim Switch als gemerged angezeigt, die anderen als updated. Die gemergte Datei behält den lokalen Inhalt der vorhandenen Arbeitskopie, statt den Inhalt aus dem Tag zu übernehmen. (es sind 2 Zeilen in der Datei betroffen).
Ist das ein Standardverhalten und wie kann es umgangen werden?
Mit freundlichen Grüßen
Jens Puruckherr
Linux-User-Group Dresden lug-dd@schlittermann.de on Mon Jan 31 2005 at 13:57 +0100 wrote:
Eine Konfigdatei wird mir beim Switch als gemerged angezeigt, die anderen als updated. Die gemergte Datei behält den lokalen Inhalt der vorhandenen Arbeitskopie, statt den Inhalt aus dem Tag zu übernehmen. (es sind 2 Zeilen in der Datei betroffen).
Ergänzung:
nach einem svn status wird genau diese eine Datei als gemerged angezeigt. Aber warum werden nicht die Änderungen aus dem Repos genommen und die lokalen Änderungen verworfen, sondern die lokalen Änderungen behalten? Habsch einen Denkfehler?
Mit freundlichen Grüßen
Jens Puruckherr
Hi,
mein Problem ist wohl grösser als angenommen, abgesehen von den technischen Problemchen, die ich vorher berichtete.
Gemäss Konrads Tipp aus einer früheren Frage, will ich nun zwischen den einzelne Releases einer Webapp 'svn switch'-en. Somit können alle Server vom Cluster am fixesten die neue Revision bekommen. Leider leider sitzen da einige Konfigfiles mitten in der Applikation, die auch noch auf jedem Webserver im Verbund geringfügig andere Werte enthalten (Servername, Ip ...). Da eine svn-Switch auch eine Art Update ist, gibt es an den Stellen in den Konfigfiles, wo die Serverabhängigen Infos sitzen, immer wieder Konflikte, die dann per Hand nachzuarbeiten sind.
1. Die Konfigfiles aus der Versionskontrolle rauszunehmen ist schlecht, da sie auch Elemente enthalten, die unter Versionskontrolle bleiben sollen.
2. Irgendwas Schlaues bauen, was pro Server (und pro Devel und Testumgebung) genau die Serverspezifischen Dinge nach dem Switch wiederherstellt ist gut, aber der Update-Konflikt ist da schon geschehen.
3. Ich mache mir die Mühe und bastel die Konfigfiles nach jedem switch wieder per Hand zurecht und hoffe nichts zu übersehen :-(
Mittelfristig ist da wohl eine Lösung in Sicht, aber die nächsten Monate sollen noch elegant über die Runden gebracht werden. Wie stelle ich das an? Vielleicht geht eine Lösung aus 1. + 2. Sooft ändern sich die Configfiles ja dann doch wieder nicht ...
Mit freundlichen Grüßen
Jens Puruckherr
On Mon, Jan 31, 2005 at 04:23:14PM +0100, Jens Puruckherr wrote:
Leider leider sitzen da einige Konfigfiles mitten in der Applikation, die auch noch auf jedem Webserver im Verbund geringfügig andere Werte enthalten (Servername, Ip ...).
Hallo Jens,
ich habe bei einem Vortrag über SVN gehört, dass man konfigurieren kann, dass Dateien mit Scripten nachbearbeitet werden. Wenn du die abweichenden Werte in einer extra Datei hälst, kannst du vielleicht die Werte in die Datei reinschreiben.
Vielleicht funktioniert dieser Script-Aufurf aber auch nur beim einchecken. (Kenne SVN noch nicht aus der Praxis)
Aber eigentlich sollte die Datei nicht in das gemeinsame Repository kommen, da sie nicht für alle Rechner einheitlich ist. Du könntest für jeden Rechner ein neues Repository oder ein neues Verzeichnis anlegen, in dem du die spezifischen Dateien pflegst.
.../wepapp/.... # fuer alle gleich .../rechner/ rechner1/blu.config rechenr2/blu.config
Auf dem Rechner kommt dann die Datei per Symlink an die Stelle:
.../wepapp/etc/blu.config ---> .../rechner/rechner1/blu.config
Thomas
On Monday 31 January 2005 14:27, Jens Puruckherr wrote:
nach einem svn status wird genau diese eine Datei als gemerged angezeigt. Aber warum werden nicht die Änderungen aus dem Repos genommen und die lokalen Änderungen verworfen, sondern die lokalen Änderungen behalten? Habsch einen Denkfehler?
Subversion tut alles, um lokale Änderungen zu erhalten.
Konrad
lug-dd@mailman.schlittermann.de
-
Jens Puruckherr -
Konrad Rosenbaum -
Thomas Guettler