Hi Ben, I tried your proposal #1 but it did not solve the problem. The output when running "mvn release:perform" seems to indicate that it worked out well in the end but nothing gets deployed so it obviously fails:
[INFO] Uploading: svn:https://oppna-program.googlecode.com/svn/maven/ maven/se/vgregion/common/profile/1.7/profile-1.7.pom [INFO] 4096/? [INFO] 8192/? [INFO] 12288/? [INFO] 16384/? [INFO] 20480/? [INFO] 24576/? [INFO] 28672/? [INFO] 30399/? [INFO] [INFO] [ERROR] Problem disconnecting from wagon - ignoring: Failed to close svn connection [INFO] [INFO] Retrieving previous metadata from svn-repo [INFO] [ERROR] Problem disconnecting from wagon - ignoring: Failed to close svn connection [INFO] [INFO] Uploading repository metadata for: 'artifact se.vgregion.common:profile' [INFO] [ERROR] Problem disconnecting from wagon - ignoring: Failed to close svn connection [INFO] [INFO] ------------------------------------------------------------------------ [INFO] [INFO] BUILD SUCCESSFUL We are using wagon-svn 1.9. Any ideas are very welcome. On Mar 17, 2:06 pm, Ben Collins-Sussman <suss...@google.com> wrote: > We just upgraded everyone to a new subversion server -- a blogpost > with more details is coming today. The new server is still based on > Bigtable, but the upshot is that it's about 3x-5x faster than our old > server (and we expect it to get even faster in the near future!) > > A number of people have been reporting sudden problems with their > continuous integration systems (or miscellaneous svn clients) suddenly > being unable to commit changes. While we haven't confirmed the causes > for sure, our suspicion is that certain svn clients (particularly ones > based on the java reimplementation of svn, 'svnkit') are being > confused by the following two new behavioral changes: > > 1. The server certificate changed for googlecode.com recently to > d0:6a:9c:61:00:b6:ea:a7:72:5d:c3:42:d8:f4:8b:9c:06:fe:bd:58 -- we'll > update the FAQ shortly. A number of non-official svn implementations > have flaky handling of SSL and may be failing silently due to the > certificate change (rather than re-prompting about whether to trust > the certificate.) If you have a working copy that used to commit just > fine over https:// and now just mysteriously fails, please try > deleting the working copy and checking out a fresh, new one (using the > troublesome svn client). Let us know if that clears things up. > > 2. The old svn server used to require unconditional authentication > when accessing an https:// URL -- reads and writes both. The new svn > server now allows anonymous SSL reads (just like our mercurial > server). It's possible that certain clients or scripts are still > expecting to authenticate when doing reads, and getting confused. -- You received this message because you are subscribed to the Google Groups "Project Hosting on Google Code" group. To post to this group, send email to google-code-host...@googlegroups.com. To unsubscribe from this group, send email to google-code-hosting+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-code-hosting?hl=en.
