wagon-svn seems to be its own home-spun svn client, and may be doing something unusual. Can you send us an HTTP trace of the traffic?
On Fri, Mar 19, 2010 at 9:17 AM, Jonas Liljenfeldt <[email protected]> wrote: > 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 <[email protected]> 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/google-code-hosting?hl=en. > > -- 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-code-hosting?hl=en.
