On Thu, Jul 19, 2012 at 4:19 PM, Sarah Woodall < sarah.wood...@code-red-tech.com> wrote:
> On 19/07/2012 21:03, Carlton Brown wrote: > >> Apparently the Jenkins Subversion Plugin 1.42 has problems updating a >> manually checked out 1.7 workspace with externals if that configuration >> setting does not specify a 1.7 format. >> > > Ah, is _that_ the way to work round the bug? I have lost so much time over > this problem! See Jenkins JIRA issue 13790. Are you telling me that all I > need to do is change this setting in the configuration and my problems will > be over? After further, I'm afraid it's a bit more subtle than that. If Jenkins had ever tried to update that WC as if it were a 1.4 WC, and encountered that error, then the Jenkins workspace metadata is somehow hosed until you wipe the workspace via Jenkins. However, if you haven't set the global WC format to 1.7, the situation will recur until you've done so. > > Apparently this setting defaults to an SVN 1.4 working copy format, at >> least that's what I observe in Jenkins 1.474. >> > > Yes, I had seen that it defaulted to 1.4. I did wonder why. I _thought_ I > had changed it to 1.7 and that I still saw the problem, but perhaps I am > confused. Another odd wrinkle to this problem is that apparently in the upgrade from SVN plugin 1.39 to 1.42, the filesystem workspace path changes from $JENKINS_HOME/workspace/$jobname to $JENKINS_HOME/jobs/$jobname/workspace. So if you are working with the WC directly at the command line, you may be interacting with a directory that Jenkins is no longer using.
