Hallo Roman,
Am 25.10.2007 um 23:00 schrieb Roman Sladeczek:
Hallo Jonathan, Stefan, Daniel, Carsten,
@Stefan, Daniel, Carsten
> Wie Stefan schon geschrieben hat kannst du damit das Problem
umgehen.
> Also normal die SVN Verbindung per Konsole herstellen,
> und das Zertifikat permanent akzeptieren. So hatte ich es damals
auch
> gemacht.
> Evtl. von einem Rechner, der schon mal auf das repo zugegriffen
hat, > ~/.subversion/auth/svn.ssl.server/nnnn auf den Zielrechner
kopieren, > bevor das repo angefasst wird. (nnnn mit grep
herausfinden...)
Dieser Workaround hat bei mir leider nicht funktioniert.
Auf welches Repository wird denn da per SSL zugegriffen? Wenn es das
eigene ist, dann gibt's ja vielleicht die Alternative ssh, wenn das
nicht geht und du cap 2.0 verwendest, könnte deploy_via :copy das
Problem auch umgehen.
Wenn es ein Plugin ist, kann ich generell nur empfehlen, das Plugin
nicht direkt beim deploy aus dem externen Repository zu ziehen
(besser: Selbst Verwalten und z.B. piston http://
piston.rubyforge.org/ verwenden).
Sind zwar alles keine direkten Lösungen, aber vielleicht ist ein
sinnvoller Workaround dabei.
Gruß,
Hendrik
_______________________________________________
rubyonrails-ug mailing list
[email protected]
http://mailman.headflash.com/mailman/listinfo/rubyonrails-ug
