I have the same problem.. I'll try to setup a trace. how would you like data (thinking I'll use jmeter's http proxy)?
My error: slurry-snapshot, so will be created Uploading: svn:https://slurry.googlecode.com/svn/maven/snapshot/maven/ snapshot/org/slurry/cache4guice/1.0-SNAPSHOT/cache4guice-1.0- SNAPSHOT.jar [ERROR] Problem disconnecting from wagon - ignoring: Failed to close svn connection [INFO] Retrieving previous metadata from slurry-snapshot [ERROR] Problem disconnecting from wagon - ignoring: Failed to close svn connection [INFO] repository metadata for: 'snapshot org.slurry:cache4guice:1.0- SNAPSHOT' could not be found on repository: slurry-snapshot, so will be created [INFO] Uploading repository metadata for: 'snapshot org.slurry:cache4guice:1.0-SNAPSHOT' [ERROR] Problem disconnecting from wagon - ignoring: Failed to close svn connection [INFO] Retrieving previous metadata from slurry-snapshot [ERROR] Problem disconnecting from wagon - ignoring: Failed to close svn connection [INFO] repository metadata for: 'artifact org.slurry:cache4guice' could not be found on repository: slurry-snapshot, so will be created [INFO] Uploading repository metadata for: 'artifact org.slurry:cache4guice' [ERROR] Problem disconnecting from wagon - ignoring: Failed to close svn connection [INFO] Uploading project information for cache4guice 1.0-SNAPSHOT [ERROR] Problem disconnecting from wagon - ignoring: Failed to close svn connection On Mar 19, 4:05 pm, Ben Collins-Sussman <[email protected]> wrote: > 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 > > athttp://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.
