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

Revert to clean check out if svn update fails because of an obstacle

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Component/s: subversion-plugin
    • Labels:
      None
    • Environment:
      Platform: All, OS: All
    • Similar Issues:

      Attachments

        Activity

        Hide
        scm_issue_link SCM/JIRA link daemon added a comment -

        Code changed in hudson
        User: : kohsuke
        Path:
        trunk/hudson/main/core/src/main/java/hudson/scm/SubversionSCM.java
        trunk/www/changelog.html
        http://fisheye4.cenqua.com/changelog/hudson/?cs=10311
        Log:
        [FIXED JENKINS-1882] If "svn update" fails because a local file is colliding with newly added files, revert to check out. This fix is in 1.228.

        Show
        scm_issue_link SCM/JIRA link daemon added a comment - Code changed in hudson User: : kohsuke Path: trunk/hudson/main/core/src/main/java/hudson/scm/SubversionSCM.java trunk/www/changelog.html http://fisheye4.cenqua.com/changelog/hudson/?cs=10311 Log: [FIXED JENKINS-1882] If "svn update" fails because a local file is colliding with newly added files, revert to check out. This fix is in 1.228.
        Hide
        lloydchang Lloyd Chang added a comment -

        Cool. Clean checkout should work. Hudson can also try a svn cleanup in
        between, in case that solves the issue
        a) svn update
        b) svn cleanup && svn update
        c) rm -rf local-module-dir && svn update

        In the event of a Windows directory or file lock, Hudson can try running the
        handle command (or equivalent) to detect which process has a lock on it.

        Show
        lloydchang Lloyd Chang added a comment - Cool. Clean checkout should work. Hudson can also try a svn cleanup in between, in case that solves the issue a) svn update b) svn cleanup && svn update c) rm -rf local-module-dir && svn update In the event of a Windows directory or file lock, Hudson can try running the handle command (or equivalent) to detect which process has a lock on it.
        Hide
        lloydchang Lloyd Chang added a comment -

        Hi Kohsuke,

        This doesn't seem to be fully fixed yet in Hudson 1.228, per description below.

        This bug isn't fixed in scenarios where local .svn directories might be out of
        synch / locked, and svn cleanup is required.

        While it seems related to "Re-implemented the SCM polling & build locking
        mechanism." at
        http://www.nabble.com/Error:-svn:-Working-copy-%3Cdir%3E-locked--try-performing-'cleanup'-td11591072.html
        I'm seeing an issue in another way. Some builds will modify a directory without
        informing SVN, causing a need for "svn cleanup" or "rm -rf && svn co"

        Below is the error message seen:

        Checking out http://subversion/trunk

        ERROR: Failed to check out http://subversion/trunk

        org.tmatesoft.svn.core.SVNException: svn: Working copy 'http://subversion/trunk'
        locked; try performing 'cleanup'
        at
        org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:55)
        at
        org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:40)
        at
        org.tmatesoft.svn.core.internal.wc.admin.SVNAdminArea14.lock(SVNAdminArea14.java:1372)
        at
        org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.doOpen(SVNWCAccess.java:353)
        at org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.open(SVNWCAccess.java:261)
        at
        org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.openAnchor(SVNWCAccess.java:153)
        at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:145)
        at org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(SVNUpdateClient.java:333)
        at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:427)
        at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:359)
        at hudson.FilePath$FileCallableWrapper.call(FilePath.java:1122)
        at hudson.remoting.UserRequest.perform(UserRequest.java:69)
        at hudson.remoting.UserRequest.perform(UserRequest.java:23)
        at hudson.remoting.Request$2.run(Request.java:200)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at
        java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
        at java.lang.Thread.run(Thread.java:619)

        To fix it, I had to log onto the agent that's having the issue, and run "rm -rf"
        on the directory in question, forcing a clean checkout the next time. Running
        "svn cleanup" didn't fix the issue.

        Show
        lloydchang Lloyd Chang added a comment - Hi Kohsuke, This doesn't seem to be fully fixed yet in Hudson 1.228, per description below. This bug isn't fixed in scenarios where local .svn directories might be out of synch / locked, and svn cleanup is required. While it seems related to "Re-implemented the SCM polling & build locking mechanism." at http://www.nabble.com/Error:-svn:-Working-copy-%3Cdir%3E-locked--try-performing-'cleanup'-td11591072.html I'm seeing an issue in another way. Some builds will modify a directory without informing SVN, causing a need for "svn cleanup" or "rm -rf && svn co" Below is the error message seen: — Checking out http://subversion/trunk ERROR: Failed to check out http://subversion/trunk org.tmatesoft.svn.core.SVNException: svn: Working copy 'http://subversion/trunk' locked; try performing 'cleanup' at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:55) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:40) at org.tmatesoft.svn.core.internal.wc.admin.SVNAdminArea14.lock(SVNAdminArea14.java:1372) at org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.doOpen(SVNWCAccess.java:353) at org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.open(SVNWCAccess.java:261) at org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.openAnchor(SVNWCAccess.java:153) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:145) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(SVNUpdateClient.java:333) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:427) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:359) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:1122) at hudson.remoting.UserRequest.perform(UserRequest.java:69) at hudson.remoting.UserRequest.perform(UserRequest.java:23) at hudson.remoting.Request$2.run(Request.java:200) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:619) — To fix it, I had to log onto the agent that's having the issue, and run "rm -rf" on the directory in question, forcing a clean checkout the next time. Running "svn cleanup" didn't fix the issue.
        Hide
        mdonohue mdonohue added a comment -

        Working around local modification to SVN controlled files is under issue 1687.
        I'm changing this back to 'fixed'

        Show
        mdonohue mdonohue added a comment - Working around local modification to SVN controlled files is under issue 1687. I'm changing this back to 'fixed'

          People

          Assignee:
          Unassigned Unassigned
          Reporter:
          kohsuke Kohsuke Kawaguchi
          Votes:
          0 Vote for this issue
          Watchers:
          0 Start watching this issue

            Dates

            Created:
            Updated:
            Resolved: