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

Workspace deleted when subversion checkout happens

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • subversion-plugin
    • None
    • Platform: All, OS: All

      When a subversion checkout is done, the entire workspace is deleted - not just
      the previous checkout folder. There may be other files held in the workspace
      outside the checkout folder - especially when the same workspace is share by
      multiple jobs. Code should be changed so that only the previous checkout
      folder, if there is one, is deleted before a checkout is done.

          [JENKINS-3580] Workspace deleted when subversion checkout happens

          kaxelson created issue -

          Code changed in hudson
          User: : kaxelson
          Path:
          trunk/hudson/main/core/src/main/java/hudson/scm/SubversionSCM.java
          http://fisheye4.cenqua.com/changelog/hudson/?cs=17550
          Log:
          JENKINS-3580: [FIXED JENKINS-3580]
          When a checkout occurs, only the existing checkout location(s) is/are deleted, not the entire workspace.

          SCM/JIRA link daemon added a comment - Code changed in hudson User: : kaxelson Path: trunk/hudson/main/core/src/main/java/hudson/scm/SubversionSCM.java http://fisheye4.cenqua.com/changelog/hudson/?cs=17550 Log: JENKINS-3580 : [FIXED JENKINS-3580] When a checkout occurs, only the existing checkout location(s) is/are deleted, not the entire workspace.
          SCM/JIRA link daemon made changes -
          Resolution New: Fixed [ 1 ]
          Status Original: Open [ 1 ] New: Resolved [ 5 ]

          Code changed in hudson
          User: : kaxelson
          Path:
          trunk/www/changelog.html
          http://fisheye4.cenqua.com/changelog/hudson/?cs=17552
          Log:
          JENKINS-3580:
          Added changelog message

          SCM/JIRA link daemon added a comment - Code changed in hudson User: : kaxelson Path: trunk/www/changelog.html http://fisheye4.cenqua.com/changelog/hudson/?cs=17552 Log: JENKINS-3580 : Added changelog message

          Within several days of a release, we have two people independently noticing this
          behavior change.

          See http://www.nabble.com/Subversion-workspace-deletion-in-1.302-td23413270.html
          and http://www.nabble.com/Issue-3580---regression-td23402321.html

          So I think we need to revert this change. kaxelson, what you can do is to write
          a plugin that subclasses SubversionSCM, and changes its behavior in a way you
          want. Your plugin can also remove SubversionSCM descriptor from the list, so
          that your Hudson has only one "Subversion" implementation.

          Would that do?

          Kohsuke Kawaguchi added a comment - Within several days of a release, we have two people independently noticing this behavior change. See http://www.nabble.com/Subversion-workspace-deletion-in-1.302-td23413270.html and http://www.nabble.com/Issue-3580---regression-td23402321.html So I think we need to revert this change. kaxelson, what you can do is to write a plugin that subclasses SubversionSCM, and changes its behavior in a way you want. Your plugin can also remove SubversionSCM descriptor from the list, so that your Hudson has only one "Subversion" implementation. Would that do?
          Kohsuke Kawaguchi made changes -
          Resolution Original: Fixed [ 1 ]
          Status Original: Resolved [ 5 ] New: Reopened [ 4 ]

          mdonohue added a comment -
              • Issue 3634 has been marked as a duplicate of this issue. ***

          mdonohue added a comment - Issue 3634 has been marked as a duplicate of this issue. ***
          mdonohue made changes -
          Link New: This issue is duplicated by JENKINS-3634 [ JENKINS-3634 ]

          kev009 added a comment -

          add cc

          kev009 added a comment - add cc

          kaxelson added a comment -

          My apologies to those whose builds were broken by this fix.

          We can certainly revert this change if necessary, but I would argue that the
          current behavior is more correct. There is a difference between the workspace
          and the checkout location. This may go unnoticed by those who have one job per
          workspace, but for those with multiple jobs sharing a single workspace, it
          becomes immediately evident. The SCM module is overstepping its bounds by
          killing the entire workspace. As I see it, the SCM module's scope should be
          limited to the checkout locations it controls.

          I'd suggest that a better solution would be to make the same change (keep
          workspace, wipeout checkout location only) in all SCM modules/plugins and create
          a build wrapper that wipes out the workspace only if that behaviour is
          explicitly requested.

          kaxelson added a comment - My apologies to those whose builds were broken by this fix. We can certainly revert this change if necessary, but I would argue that the current behavior is more correct. There is a difference between the workspace and the checkout location. This may go unnoticed by those who have one job per workspace, but for those with multiple jobs sharing a single workspace, it becomes immediately evident. The SCM module is overstepping its bounds by killing the entire workspace. As I see it, the SCM module's scope should be limited to the checkout locations it controls. I'd suggest that a better solution would be to make the same change (keep workspace, wipeout checkout location only) in all SCM modules/plugins and create a build wrapper that wipes out the workspace only if that behaviour is explicitly requested.

            kaxelson kaxelson
            kaxelson kaxelson
            Votes:
            5 Vote for this issue
            Watchers:
            12 Start watching this issue

              Created:
              Updated:
              Resolved: