Hallo,
ich kann schon seit mehreren Tagen nichts auf sourceforge hochspielen. Laut dem "codechange"-Forum geht es anscheinend nicht nur mir so. Weiß einer was los ist?
tupol
Commit failed (details follow):
Unable to connect to a repository at URL
'https://svn.code.sf.net/p/fhem/code/trunk/fhem/FHEM'
Error running context: Es konnte keine Verbindung hergestellt werden, da der
Zielcomputer die Verbindung verweigerte.
Geht mir genau so. Ich warte schon seid 2 Tagen, dass die Committs wieder gehen. Die Leute von SF arbeiten wohl daran.
Gruss
Denen hat es angeblich das storage gekostet. Hoffen wir mal, dass zumindest denen ihr disaster recovery was taugt.
SF ist echt 'ne traurige Geschichte. Schon zwei Tage down ...
Auch deswegen traurig, weil es inzwischen nicht mal Schlagzeilen macht.
Letzter Status auf https://twitter.com/sfnet_ops (https://twitter.com/sfnet_ops) ist von Freitag:
#SourceForge (https://twitter.com/hashtag/SourceForge?src=hash) directory, download and project summary pages are back online; dev services (SCM, uploads, ML's, project web) pending restoral
Ich habe ein Backup des Subversion-Baumes (taeglich erstellt, letzte Version ist 8980), ich wuerde allerdings mit einem vorzeitigen Umzug noch etwas warten, und darauf hoffen, dass sie den Restore hinkriegen. Es gibt auch einen geplanten Umzug von sourceforge, das wird aber noch ein/zwei Monate dauern.
Hallo Rudi,
Zitat von: rudolfkoenig am 19 Juli 2015, 07:41:04
Ich habe ein Backup des Subversion-Baumes (taeglich erstellt, letzte Version ist 8980), ich wuerde allerdings mit einem vorzeitigen Umzug noch etwas warten, und darauf hoffen, dass sie den Restore hinkriegen. Es gibt auch einen geplanten Umzug von sourceforge, das wird aber noch ein/zwei Monate dauern.
darf man fragen WOHIN der Umzug gehen soll?
Wäre es vielleicht auch möglich ein Archiv mit der Version 8980 irgendwo zum Download hinzulegen? Ich wollte gerade meine Testinstallation updaten, das geht jetzt natürlich nicht... ,-(
WebSpace zum Download könnte ich anbieten falls nötig.
Gruß,
Andreas.
Zitatdarf man fragen WOHIN der Umzug gehen soll?
Auf eigene Server, Details dann wenn es fertig ist.
ZitatWäre es vielleicht auch möglich ein Archiv mit der Version 8980 irgendwo zum Download hinzulegen?
http://fhem.de/fhem-svn8980.tar.gz (http://fhem.de/fhem-svn8980.tar.gz)
Hallo Rudi,
Zitat von: rudolfkoenig am 19 Juli 2015, 09:28:23
Auf eigene Server, Details dann wenn es fertig ist.
http://fhem.de/fhem-svn8980.tar.gz (http://fhem.de/fhem-svn8980.tar.gz)
super, Danke!
Andreas.
sourceforge scheint wieder zu laufen. Leider konnte ich aber nicht alle Dateien hochladen. Bei einer erhalte ich z.B. folgenden Fehler:
Commit failed (details follow):
Base checksum mismatch on '/trunk/fhem/FHEM/72_FRITZBOX.pm':
expected: 5c83a7644e60e18d214543856bc51404
actual: f25e242d6509ad07c2aa5a222c14e0dc
Läßt sich das lösen oder muss da noch was durch die sf Leute passieren?
Gruß
tupol
krikan hat mich eben darauf hingewiesen das scheinbar noch etwas schief läuft bei sf. die commits vom 16. scheinen zumindest was die kommentare angeht mit denen von heute vermischt zu werden.
vermutlich ist es besser noch etwas zu warten bevor noch mehr eingecheckt bzw. versucht wird hier etwas zu reparieren.
gruss
nadre
Hi,
sind denn auch Probleme mit dem Code bekannt oder betrifft es "nur" die Kommentare? Ich hatte nämlich heute morgen gewohnheitsmäßig SVN gestartet und es hat mir zumindest mal einige Files geliefert...
Gruß,
Andreas.
zumindest meine commits scheinen laut hisotry inhaltlich ok zu sein.
Ok, danke!
Dann gehe ich mal davon aus das soweit alles gut ist ,-)
Gruß,
Andreas.
So ganz haut das nicht hin. Hat jemand schon erfolgreich ein Update hinbekommen?
Bei mir endet das damit (TortoiseSVN):
Update failed
Checksum mismatch for '...\fhem\CHANGED':
expected: bf1a3ef0dbee9652e649dc3f3a0db535
recorded: fa1e3caf283d578f5586f143c47a59d4
Try a 'Cleanup'. If that doesn't work you need to do a fresh checkout.
Ein Cleanup hat es auch nicht verbessert. Dann werde ich es halt doch mal neu auschecken.
bei mir hat es heute funktioniert.
OK, ein neuer checkout hat funktioniert und auf dem geht auch das update dann wieder.
Seltsame Sache. Irgendwie habe ich ein mulmiges Gefühl bei der Sache, ob die das wirklich wieder richtig im Griff haben ...
Bei mir läuft es nach wie vor nicht: Base checksum mismatch on '/trunk/fhem/FHEM/72_FRITZBOX.pm':
SourceForge hat Version 8978 restauriert, ich habe danach noch 8979 gesichert, ich meine der letzte commit war von andre. Evtl. gab es auch weitere commits, die ich mit meinem Backup um 0745 verpasst habe. Da ihr inzw. schon fleissig eingecheckt habt, kann ich meine Version nicht mehr restaurieren.
Diejenigen, die nach der Sicherung von SourceForge ein update gemacht haben, müssen alles neu auschecken.
Das gleiche Problem habe ich mit fhemupdate, da ich gerade nur mit Telefon ausgerüstet bin, wird das etwas nerwig.
Btw. culfw hat das gleiche Problem.
mein 8979 commit hat zwar in der history den kommentar des commits von gestern aber die änderung ist dabei.
Zitat von: justme1968 am 27 Juli 2015, 09:10:57
mein 8979 commit hat zwar in der history den kommentar des commits von gestern aber die änderung ist dabei.
Da spielt Dir wahrscheinlich das lokale Repository einen Streich. In einer neu ausgecheckten Arbeitskopie passt der Inhalt von 8979 zum Kommentar (von gestern).
Ich habe bei mir das .svn-Verzeichnis eines neuen Checkouts in meinen alten kopiert, jetzt passt auch der wieder und ich habe noch ein paar Aenderungen, die nicht mehr im Repository enthalten sind:
M FHEM/00_ZWDongle.pm
M FHEM/01_FHEMWEB.pm
M FHEM/10_SOMFY.pm
M FHEM/30_HUEBridge.pm
M FHEM/55_GDS.pm
M FHEM/72_FRITZBOX.pm
M FHEM/73_km200.pm
M configDB.pm
M docs/fhem.html
M docs/fhem_DE.html
M www/pgm2/fhemweb.js
Habe ich auch mal als Diff angehaengt.
Zitat von: rudolfkoenig am 27 Juli 2015, 07:44:47
Btw. culfw hat das gleiche Problem.
Sollte wieder auf dem aktuellen Stand sein.
Viele Gruesse
Michael
nein. das ist es nicht. ich hatte direkt auf sourceforge in der history nachgeschaut (http://sourceforge.net/p/fhem/code/8979/ (http://sourceforge.net/p/fhem/code/8979/)). da ist der commit 8979 mit dem kommentar und dem timestamp vom 15.07. an 30_HUEBridge.pm mit dem änderungen von gestern an 31_HUEDevice.pm vermischt. svn log auf ein altes oder neu ausgechecktes repositiory zeigt den richtigen kommentar zum richtigen file. aber auch als 8979.
inzwischen habe ich auch gesehen das die echte 8979 änderung nicht mehr da ist. svn beschwert sich aber auch nicht.
die version 8979 scheint als zwei mal vergeben worden zu sein. die frage ist ob noch mehr nicht stimmt.
gruss
andre
Hi,
Zitat von: justme1968 am 27 Juli 2015, 10:27:42
die version 8979 scheint als zwei mal vergeben worden zu sein. die frage ist ob noch mehr nicht stimmt.
Da kam eine Mail von sf, die das evtl. erklaert:
Zitat
To determine which repositories are missing recent commits, we compared the
revision count currently in your repository on disk (Current revision on disk)
to the revision count seen by our repository tracking (Current revision in database).
The repository tracking database does not house a full copy of your commit data.
Wahrscheinlich benutzt das Web-Interface die (jetzt) inkonsistente Datenbank fuer die Kommentare...
Viele Gruesse
Michael
ich konnte jetzt auch den "base checksum"-Fehler umgehen, indem ich das Modul in sf gelöscht und wieder aufgespielt haben.
Läuft eigentlich das FHEM-Update wieder?
bei 30_HUEBridge.pm hat auch nur remove und add geholfen.
Ich habe meine vorbereiteten Änderungen eingecheckt, indem ich alles neu ausgecheckt habe, und die geänderten Dateien rueberkopiert habe. Durch Loeschen und neu Hinzufügen geht die Historie verloren.
So habe ich das auch gemacht.
Eben ist mir gerade aufgefallen, dass ein "update check" in FHEM mir das komplette FHEM als geändert listet.
Ist das gewollt oder auch ein Auswirkung der SF-Geschichte?
Das war gestern oder vorgestern (bin mir nicht ganz sicher) noch nicht so.
Das is eine Folge des Sourceforge Problems, siehe diesen (http://forum.fhem.de/index.php/topic,39552.msg320639.html#msg320639) Beitrag.
Die lange und unvollstaendige Liste der update-Zeilen hier anzuhaengen ist unnnoetig, und dient hoechstens zum Aergern der Leser.
Habe den Grund zur Verärgerung entfernt. Da hat leider der code block, den ich aus diesem Grund drum rum hatte, wohl aufgrund der Länge versagt.
Hat SF schon wieder Schwierigkeiten?
Ich kann zwar auschecken, bekomme aber beim Commit (über SourceTree bzw. Git-Svn / Pull) einen Fehler bei der Authentifizierung angezeigt... :o
Du bist nicht alleine mit dem Problem 8)
Ich habe gerade meinen commit ohne Probleme durchbekommen. Mit TortoiseSVN.
Bei mir nach wie vor die Fehlermeldung (egal ob SVN von der Kommandozeile oder beliebige GUI Tools)
ERROR from SVN:
URL access forbidden for unknown reason: Access to '/p/fhem/code/!svn/me' forbidden
Das Auschecken funktioniert problemlos.
Nachtrag: Das Problem scheint nur aufzutreten, wenn man mit "git svn" versucht, auf das sourceforge repository zuzugreifen. Mit einem reinen svn Tool konnte ich nun auch erfolgreich einen commit durchführen.
Ich habe irgendwie das letzte Yosemite Update 10.10.5 in Verdacht...
Ja, kann ich bestätigen. Muss ich wohl in 30 Tagen die $60 in Versions als GUI-Client investieren... :-\
Ich nutze nicht Git aus den OSX Command Line Tools, sondern die neuere Version über Homebrew.
Wie weit sind denn die Umstellungspläne auf Git fortgeschritten?
Zitat von: Loredo am 26 August 2015, 12:30:57
Ja, kann ich bestätigen. Muss ich wohl in 30 Tagen die $60 in Versions als GUI-Client investieren...
Musst Du nicht :) Stell mal in Deinem git-svn repository die URL von http auf https um, dann funktioniert alles wieder. Sourceforge läßt wohl http nur noch für read-only zu, wer auch schreiben will, muss sich über https verbinden.
Abgesehen davon: Die Arbeit mit Versions macht auch Spaß.
SF möchte ja, dass man SSH benutzt und das tue ich schon seit jeher:
svn+ssh://loredo@svn.code.sf.net/p/fhem/code/trunk
Auschecken geht, nur einchecken eben nicht. Bei https gibts gleich nen Fehler "invalid source" :'(
Wenn man SourceTree gewohnt ist, dann ist Versions total schrecklich zu bedienen (teils sicherlich auch SVN bedingt). Die XCode Tools für Diff sind leider ein Graus.
Naja, bleibt wohl erstmal nichts anderes als auf den Umstieg auf Git zu hoffen.
Gestern habe ich von http auf https umgestellt und das commit funktioniert wieder einwandfrei.
Wenn bei Dir "invalid source" erscheint, solltest Du die verwendete URL prüfen. Bei mir sieht die Konfiguration so aus:
(http://up.picr.de/22963014ek.png)
(ohne trunk am Ende der URL!)
Ich werde auch mal mit svn+ssh:// testen, das hatte ich bisher noch nie zusammen mit git-svn verwendet. Mich interessiert, woher der Fehler dabei kommt.
Leider kein Glück. Ich denke es liegt bei mir daran, dass ich bereits El Capitan verwende und das OSX Framework bei Aufruf von URLs mit Zugangsdaten eine Phishing Warnung ausgibt (zumindest wenn ich https://loredo@svn.code.sf.net/p/fhem/code (https://loredo@svn.code.sf.net/p/fhem/code) direkt im Safari öffne). Vielleicht handhabt auch die Tower.app das anders. Konnte mich mit dem Tower leider auch nie anfreunden (auch das erwerben einer Lizenz brachte mich nicht dazu).
Hach, die Welt ist schwer und ungerecht... :-\
Die Warnmeldung bei URL mit Benutzernamen gab es aber auch schon vor El Capitan ...
Ich habe nun fhem in Tower mit svn+ssh:// per git-svn ausgecheckt (das dauert schon mal 3-4 Stunden...) und konnte danach auch mit diesem Protokoll eine Änderung völlig fehlerfrei einchecken.
Zitat von: Loredo am 30 August 2015, 10:47:41
Ich denke es liegt bei mir daran, dass ich bereits El Capitan verwende
Einchecken per git-svn funktioniert hier auch nach dem Update auf El Capitan noch problemlos.
(http://up.picr.de/23015151zr.png)
Extra für diesen Test habe ich diese beta Version (beta6) installiert :)
klemmt scheinbar grade mal wieder... :o
was ist denn nun schon wieder?
Commit failed (details follow):
Can't open file '/svn/p/fhem/code/db/txn-current-lock': Permission denied
Vielleicht zu viele commits auf einmal.
Bei mir geht es.
@rudi: Wie peinlich für mich, dabei versuche ich immer die 80 Zeichen/Zeile einzuhalten. :-\