Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-10222

Jenkins cleaning out workspace unnecessarily when polling SCM (SVN)

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • subversion-plugin
    • None
    • Windows

      I am using a SVN repository which is being checked out at the beginning of every build in a Jenkins job. It is set to "poll SCM" for updates. However, regardless of whether there were changes or not it is cleaning out the workspace and downloading the whole repository in it's entirety every time which is unnecessary.

      Builds are taking much longer than they should as the SVN poll should only be checking out newly-updated files. Sample log:

      Checking out a fresh workspace because the workspace is not file://PICKLE/Repositories/project
      Cleaning workspace.....

          [JENKINS-10222] Jenkins cleaning out workspace unnecessarily when polling SCM (SVN)

          Giles Dermody created issue -

          Switched component to subversion plugin as it is not related to scm-sync-configuration plugin

          Frédéric Camblor added a comment - Switched component to subversion plugin as it is not related to scm-sync-configuration plugin
          Frédéric Camblor made changes -
          Component/s New: subversion [ 15485 ]
          Component/s Original: scm-sync-configuration [ 15757 ]

          cjmaynar added a comment -

          I'm experiencing what I think is the same problem still. Jenkins is correctly polling my SVN repo, but everytime it polls it adds the following log even if there are no changes, and then begins to rebuild the project:

          Workspace doesn't contain svn://my_server:/svn/repos/my_project/trunk. Need a new build.
          Done. Took 21ms
          Changes found

          cjmaynar added a comment - I'm experiencing what I think is the same problem still. Jenkins is correctly polling my SVN repo, but everytime it polls it adds the following log even if there are no changes, and then begins to rebuild the project: Workspace doesn't contain svn://my_server:/svn/repos/my_project/trunk. Need a new build. Done. Took 21ms Changes found

          Changed assignee since not related to scm-sync-config plugin

          Frédéric Camblor added a comment - Changed assignee since not related to scm-sync-config plugin
          Frédéric Camblor made changes -
          Assignee Original: Frédéric Camblor [ fcamblor ]

          Jeff Payne added a comment -

          I found one way to reproduce this: if I check out more than one path and I don't specify a target directory, it appears that the subsequent check-outs corrupt the files in the .svn subdirectory. Specifying a different target for each make it work correctly.

          I also googled and found an example where the user used different capitalization for the host name than was stored in the .svn, and had the same effect.

          Hope this helps!

          Jeff Payne added a comment - I found one way to reproduce this: if I check out more than one path and I don't specify a target directory, it appears that the subsequent check-outs corrupt the files in the .svn subdirectory. Specifying a different target for each make it work correctly. I also googled and found an example where the user used different capitalization for the host name than was stored in the .svn, and had the same effect. Hope this helps!

          Damien Finck added a comment - - edited

          Hello,

          I have exactly the same problem.

          In Jenkins, I have about 30 projects.
          For two of my projects, I have this problem for some time.

          The first one has this configuration:

          • An SVN repository on "https://<company>.fr:433/svn/<project>" in the folder "trunk" of my workspace
          • "Use 'svn update' as much as possible"
            And at each build, Jenkins said "Checking out a fresh workspace Because The workspace is not "https://<company>.fr:443/svn/<project>" "

          For the second project that is the problem, it is configured this way:

          • 3 SVN repositories
          • https://<company>.fr/svn/<project1> in the folder "project1"
          • https://<company>.fr:433/svn/<project2> in the "Project2"
          • https://<company>.fr:433/svn/<project3> in the "project3"
          • "Use 'svn update' as much as possible"
            And at each build, Jenkins said "Checking out a fresh workspace Because The workspace is not "https://<company>.fr:443/svn/<project3>" "
            I have a problem only on the third repositorie.

          I tried to remove the first project and recreate it: Same problem.

          I read in a forum user who said: "I had a similar problem .... but It Was Because The name of the SVN server in my path Was in CAPS. I changed it to lower case and it worked. ... "
          So, I changed my path from https://<company>.fr:433/svn/<folder> to https://<company>.fr/svn/<folder> and it works in my two projects .

          It like if repositorie has once time a bug, Jenkins do each other time a "svn checkout" on this repositorie instead of an "svn update".

          Version :
          Jenkins : 1.474
          Jenkins Subversion Plug-in : 1.42
          Subversion version (in Jenkins configuration) : 1.7

          Sincerely,
          Damien

          Damien Finck added a comment - - edited Hello, I have exactly the same problem. In Jenkins, I have about 30 projects. For two of my projects, I have this problem for some time. The first one has this configuration: An SVN repository on "https://<company>.fr:433/svn/<project>" in the folder "trunk" of my workspace "Use 'svn update' as much as possible" And at each build, Jenkins said "Checking out a fresh workspace Because The workspace is not "https://<company>.fr:443/svn/<project>" " For the second project that is the problem, it is configured this way: 3 SVN repositories https://<company>.fr/svn/<project1> in the folder "project1" https://<company>.fr:433/svn/<project2> in the "Project2" https://<company>.fr:433/svn/<project3> in the "project3" "Use 'svn update' as much as possible" And at each build, Jenkins said "Checking out a fresh workspace Because The workspace is not "https://<company>.fr:443/svn/<project3>" " I have a problem only on the third repositorie. I tried to remove the first project and recreate it: Same problem. I read in a forum user who said: "I had a similar problem .... but It Was Because The name of the SVN server in my path Was in CAPS. I changed it to lower case and it worked. ... " So, I changed my path from https://<company>.fr:433/svn/<folder> to https://<company>.fr/svn/<folder> and it works in my two projects . It like if repositorie has once time a bug, Jenkins do each other time a "svn checkout" on this repositorie instead of an "svn update". Version : Jenkins : 1.474 Jenkins Subversion Plug-in : 1.42 Subversion version (in Jenkins configuration) : 1.7 Sincerely, Damien

          Damien Finck added a comment - - edited

          Hello,

          I tried to reproduce the problem, but I'm not happened.
          In all my jobs I remove the port SVN URL (https://<company>.fr:433/svn/<project> to https://<company>.fr/svn/<project>)) and since I have no problem!

          Sincerely,
          Damien

          Damien Finck added a comment - - edited Hello, I tried to reproduce the problem, but I'm not happened. In all my jobs I remove the port SVN URL (https://<company>.fr:433/svn/<project> to https://<company>.fr/svn/<project>)) and since I have no problem! Sincerely, Damien

          I had the same problem with a project with the Repository URL of the following pattern:
          svn://<servername>/applications/xxx//trunk/yyy

          The polling message was:
          Workspace doesn't contain svn://<servername>/applications/xxx//trunk/yyy. Need a new build.

          However, the polling did work successfully (no changes, at revision...) when I set the Repository URL to
          svn://<servername>/applications/xxx/trunk/yyy
          (without the second slash after xxx).

          It seems that the repository url in the working copy is normalized (e.g. removing double slashes, port number) by the svn client, but the check if the working copy matches the project does not perform this kind of normalization.

          Jenkins ver. 1.471
          Subversion Plugin version 1.4

          Andreas Schoen added a comment - I had the same problem with a project with the Repository URL of the following pattern: svn://<servername>/applications/xxx//trunk/yyy The polling message was: Workspace doesn't contain svn://<servername>/applications/xxx//trunk/yyy. Need a new build. However, the polling did work successfully (no changes, at revision...) when I set the Repository URL to svn://<servername>/applications/xxx/trunk/yyy (without the second slash after xxx). It seems that the repository url in the working copy is normalized (e.g. removing double slashes, port number) by the svn client, but the check if the working copy matches the project does not perform this kind of normalization. Jenkins ver. 1.471 Subversion Plugin version 1.4

            Unassigned Unassigned
            giles Giles Dermody
            Votes:
            17 Vote for this issue
            Watchers:
            18 Start watching this issue

              Created:
              Updated: