{"id":319,"date":"2019-03-27T14:33:23","date_gmt":"2019-03-27T14:33:23","guid":{"rendered":"https:\/\/www.cssec.de\/blog\/?p=319"},"modified":"2019-03-27T14:33:23","modified_gmt":"2019-03-27T14:33:23","slug":"refactoring_svn_https","status":"publish","type":"post","link":"https:\/\/www.cssec.de\/blog\/2019\/03\/27\/refactoring_svn_https\/","title":{"rendered":"Refactoring-Probleme mit SVN und HTTPS"},"content":{"rendered":"

Hallo mal wieder,<\/p>\n

nach dem politischen Beitrag von gestern nun mal wieder etwas, was mir heute im Zuge eines Eincheck-Versuchs aus Eclipse ins Subversion passiert ist.
\nDas Cutworks-Projekt haben wir damals relativ modular aufgebaut, daraus sind dann relativ viele voneinander abh\u00e4ngige (Maven-)Projekte entstanden. Gestern habe ich eine Komponente, die bisher nur in einem Modul\/Projekt genutzt wurde, nochmals in einem anderen Modul \/ Projekt ben\u00f6tigt. Treu dem DRY-Prinzip (Don’t Repeat Yourself), habe ich daher ein Refactoring in Eclipse durchgef\u00fchrt und die entsprechenden Klassen und Dateien \u00fcber die move-Funktion ins neue Projekt verschoben. Wie immer ging das sehr problemlos.<\/p>\n

Probleme bereitete dagegen heute das Checkin ins Subversion, welches wir auf dem Cutworks-Server \u00fcber DAV und https selbst hosten. Da kam n\u00e4mlich beim Einchecken die Fehlermeldung: 502 Bad Gateway und zwar bei der ersten Datei, die ich \u00fcber Eclipse umbewegt\/refactored habe.<\/p>\n

Da das Deployment \u00fcber einen Jenkins erfolgt, ist ein Einchecken zwingend notwendig, um eine neue Version bauen zu k\u00f6nnen bzw. an anderer Stelle weiter arbeiten zu k\u00f6nnen.<\/p>\n

Nach einer Weile Google-Recherche habe ich dann herausgefunden, dass SVN so klug ist und ein Eclipse-Move in ein DAV copy bzw. DAV move-Befehl auf dem Server umschreibt und das funktioniert bei https nicht. Na Klasse.
\nDa ich auch nicht bereit war, alles zu reverten und wieder von vorne anzufangen, habe ich noch einen Weg gesucht, das einfach auf http umzustellen, dar\u00fcber soll es ja prinzipiell funktionieren, zumal das Repository sowieso auch \u00fcber http verf\u00fcgbar ist.<\/p>\n

Dazu bin ich nach der Anleitung aus Stackoverflow gefolgt:
\nhttps:\/\/stackoverflow.com\/questions\/6979872\/svn-switch-with-relocate-in-eclipse<\/a><\/p>\n

also rechte Maustaste -> relocate und dort statt https:\/\/xx.xx.x.x dann http:\/\/xx.xx.x.x angegeben. Und es hat nicht funktioniert, weil wieder eine Fehlermeldung kam:<\/p>\n

Invalid source URL prefix: https:\/\/xx.xx.x.x\/…. ( does not overlap target’s URL http:\/\/xx.xx.x.x\/…. )<\/p>\n

Also war ich total in der Zwickm\u00fchle. So konnte ich weder auf http wechseln noch meine Sourcen einchecken.\u00a0 Also blieb mir nichts anderes \u00fcbrig, als das auf der Kommandozeile aufzurufen. Zur Installation eines Subversion-Windows-Clients hatte ich eigentlich keine Lust, daher habe ich mein Ubuntu im Windows Linux Subsystem gestartet und dort mit:<\/p>\n

apt-get install subversion<\/pre>\n
den Subversion-Client fix installieren lassen und dann auf allen meinen Projekten die folgende Befehle ausgef\u00fchrt:<\/p>\n
Mit<\/p>\n
svn info<\/pre>\n
habe ich erst einmal gecheckt, ob denn die URL’s entsprechend auf https standen. Wenn ja, habe ich dann folgenden Befehl ausgef\u00fchrt:<\/p>\n
svn relocate https:\/\/xx.xx.x.x\/... http:\/\/xx.xx.x.x\/...<\/pre>\n
Dann konnte man die korrekte Einstellung noch einmal \u00fcberpr\u00fcfen:<\/p>\n
svn info<\/pre>\n
Hier war dann tats\u00e4chlich die URL auf http gestellt.
\nMit:<\/p>\n
svn update<\/pre>\n
konnte ich dann noch einmal sicherstellen, dass die Umstellung geklappt hat.<\/p>\n
Nachdem ich alle Projekte relocated habe, habe ich dann Eclipse neu gestartet und danach ging auch das Einchecken wieder problemlos.<\/p>\n
Solltet Euch nichts anderes \u00fcbrig bleiben und ihr M\u00dcSST https f\u00fcrs SVN nutzen, verzichtet am besten in Eclipse auf Move bzw. Refactor-Operationen und legt Euch statt dessen jeweils neue Klassen \/ Dateien an, die ihr dann entsprechend mit dem Inhalt der „alten“ Klassen f\u00fcllt. Anschlie\u00dfend k\u00f6nnt ihr die alten wegwerfen, dann sollte das Einchecken eigentlich problemlos klappen.<\/p>\n","protected":false},"excerpt":{"rendered":"
Hallo mal wieder, nach dem politischen Beitrag von gestern nun mal wieder etwas, was mir heute im Zuge eines Eincheck-Versuchs aus Eclipse ins Subversion passiert ist. Das Cutworks-Projekt haben wir damals relativ modular aufgebaut, daraus sind dann relativ viele voneinander abh\u00e4ngige (Maven-)Projekte entstanden. Gestern habe ich eine Komponente, die bisher nur in einem Modul\/Projekt genutzt […]<\/p>\n","protected":false},"author":1,"featured_media":321,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[11],"tags":[],"_links":{"self":[{"href":"https:\/\/www.cssec.de\/blog\/wp-json\/wp\/v2\/posts\/319"}],"collection":[{"href":"https:\/\/www.cssec.de\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.cssec.de\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.cssec.de\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.cssec.de\/blog\/wp-json\/wp\/v2\/comments?post=319"}],"version-history":[{"count":3,"href":"https:\/\/www.cssec.de\/blog\/wp-json\/wp\/v2\/posts\/319\/revisions"}],"predecessor-version":[{"id":323,"href":"https:\/\/www.cssec.de\/blog\/wp-json\/wp\/v2\/posts\/319\/revisions\/323"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.cssec.de\/blog\/wp-json\/wp\/v2\/media\/321"}],"wp:attachment":[{"href":"https:\/\/www.cssec.de\/blog\/wp-json\/wp\/v2\/media?parent=319"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.cssec.de\/blog\/wp-json\/wp\/v2\/categories?post=319"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.cssec.de\/blog\/wp-json\/wp\/v2\/tags?post=319"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}