[JIRA] [subversion-plugin] (JENKINS-30046) SVN Plugin reports "E160004: Malformed representation header" with Tortoise

[ken.nicolson@jp.panasonic.com (JIRA)]

Ken Yasumoto-Nicolson created an issue

Jenkins / JENKINS-30046 SVN Plugin reports "E160004: Malformed representation header" with Tortoise Issue Type: Bug Assignee: Unassigned Components: subversion-plugin Created: 20/Aug/15 2:33 AM Environment: Windows 8/32 bit, Jenkins 1.624, SVN Plugin 2.5.2, TortoiseSVN 1.9.0. Priority: Major Reporter: Ken Yasumoto-Nicolson Since upgrading to TortoiseSVN 1.9.0, in Project Configuration/Source Code Management/Subversion Modules, my Repository URL of file:///C:/SVNRepository/trunk/blahblah gives a "Malformed representation header" error. Builds also produce a similar error. Note I use no credentials. TortoiseSVN itself works as before. The error displayed is: Unable to access file:///C:/SVNRepository/trunk/blahblah : svn: E160004: Malformed representation header 'DELTA 116 17463 103' org.tmatesoft.svn.core.SVNException: svn: E160004: Malformed representation header 'DELTA 116 17463 103' at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.fs.FSFS.getDirContents(FSFS.java:898) at org.tmatesoft.svn.core.internal.io.fs.FSRevisionNode.getDirEntries(FSRevisionNode.java:607) at org.tmatesoft.svn.core.internal.io.fs.FSRevisionNode.getChildDirNode(FSRevisionNode.java:588) at org.tmatesoft.svn.core.internal.io.fs.FSRoot.openPath(FSRoot.java:96) at org.tmatesoft.svn.core.internal.io.fs.FSRoot.getRevisionNode(FSRoot.java:53) at org.tmatesoft.svn.core.internal.io.fs.FSRoot.checkNodeKind(FSRoot.java:139) at org.tmatesoft.svn.core.internal.io.fs.FSRepository.checkPath(FSRepository.java:212) at hudson.scm.SubversionSCM$DescriptorImpl.checkRepositoryPath(SubversionSCM.java:2320) at hudson.scm.SubversionSCM$ModuleLocation$DescriptorImpl.checkCredentialsId(SubversionSCM.java:3091) at hudson.scm.SubversionSCM$ModuleLocation$DescriptorImpl.doCheckCredentialsId(SubversionSCM.java:3064) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:298) at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:161) at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:96) at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:121) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:249) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:249) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:649) at org.kohsuke.stapler.Stapler.service(Stapler.java:238) at javax.servlet.http.HttpServlet.service(HttpServlet.java:848) at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:686) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1494) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:132) at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:123) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:49) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76) at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:171) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) at org.kohsuke.stapler.compression.CompressionFilter.doFilter(CompressionFilter.java:49) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) at hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) at org.kohsuke.stapler.DiagnosticThreadNameFilter.doFilter(DiagnosticThreadNameFilter.java:30) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1474) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:533) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:428) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116) at org.eclipse.jetty.server.Server.handle(Server.java:370) at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489) at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:949) at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1011) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235) at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82) at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:668) at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52) at winstone.BoundedExecutorService$1.run(BoundedExecutorService.java:77) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Add Comment

This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)

[ken.nicolson@jp.panasonic.com (JIRA)]

Ken Yasumoto-Nicolson updated an issue

Jenkins / JENKINS-30046

"E160004: Malformed representation header" with TortoiseSVN 1.9.0 Change By: Ken Yasumoto-Nicolson Summary: SVN Plugin reports  "E160004: Malformed representation header" with  Tortoise  TortoiseSVN 1.9.0

Add Comment

[ken.nicolson@jp.panasonic.com (JIRA)]

Ken Yasumoto-Nicolson commented on JENKINS-30046

Re: "E160004: Malformed representation header" with TortoiseSVN 1.9.0 I've narrowed the problem down to, I think, DELTA instead of PLAIN revision summaries in my revision log files. See [this Stack Overflow question](http://stackoverflow.com/q/32109952/1270789) for more details.

Add Comment

[ken.nicolson@jp.panasonic.com (JIRA)]

Ken Yasumoto-Nicolson edited a comment on JENKINS-30046

Re: "E160004: Malformed representation header" with TortoiseSVN 1.9.0

I've narrowed the problem down to, I think, *DELTA* instead of *PLAIN* revision summaries in my revision log files. See [this Stack Overflow question ]( | http://stackoverflow.com/q/32109952/1270789 ) ]  for more details.

Add Comment

[ron.ahonen@schneider-electric.com (JIRA)]

Ron Ahonen commented on JENKINS-30046

Re: "E160004: Malformed representation header" with TortoiseSVN 1.9.0

I had the same issue. Reading SVN 1.9 release notes afterwards, it is mentioned in section 'Changed deltification defaults' how to keep old behaviour: [deltification] enable-dir-deltification = false enable-props-deltification = false I dumped my repo, created a new one, changed the settings and loaded the dump. Now Jenkins subversion-plugin is happy again and I can use SVN 1.9 client.

Add Comment

[ken.nicolson@jp.panasonic.com (JIRA)]

Ken Yasumoto-Nicolson commented on JENKINS-30046

Re: "E160004: Malformed representation header" with TortoiseSVN 1.9.0

Ron Ahonen That seemed to do the trick! Note that this needs an extra flag when creating the new repo: svnadmin create --compatible-version 1.8 SVNRepository The subversion-plugin hasn't been updated to handle 1.9 repositories.

Add Comment

[recena@gmail.com (JIRA)]

Manuel Jesús Recena Soto commented on JENKINS-30046

Re: "E160004: Malformed representation header" with TortoiseSVN 1.9.0

Ken Yasumoto-Nicolson What is the relation with Subversion Plugin? A working copy created by a Jenkins Job should be only managed by Jenkins.

Add Comment

[recena@gmail.com (JIRA)]

Manuel Jesús Recena Soto assigned an issue to Manuel Jesús Recena Soto

Jenkins / JENKINS-30046

"E160004: Malformed representation header" with TortoiseSVN 1.9.0

Change By: Manuel Jesús Recena Soto Assignee: Manuel Jesús Recena Soto

Add Comment

[recena@gmail.com (JIRA)]

Manuel Jesús Recena Soto closed an issue as Not A Defect

Jenkins / JENKINS-30046 "E160004: Malformed representation header" with TortoiseSVN 1.9.0

Change By: Manuel Jesús Recena Soto

Status: Open Closed Resolution: Not A Defect

Add Comment

[ron.ahonen@schneider-electric.com (JIRA)]

Ron Ahonen commented on JENKINS-30046

Re: "E160004: Malformed representation header" with TortoiseSVN 1.9.0 For file based repositories, subversion client acts as both client and server. There svnkit operates not only on the local working copy, but also on the repository. Using new 1.9 SVN client changed the repository in such a way, that the old svnkit 1.7.10 used in subversion plugin couldn't make sense of the repository any more. Current svnkit versions can handle the changed repository.

Add Comment