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

SVN external folders are empty after checkout

    Details

    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: subversion-plugin
    • Labels:
      None
    • Environment:
      Hudson ver. 1.348

      Description

      SVN Source-Code-Management does not seem to handle SVN external folders correctly. They are empty in the hudson workspace after checkout.

        Activity

        Hide
        kocar kocar added a comment -

        In my case the external folders are not created at all... The directory "!depend", which has svn:externals property set, has no subdirectories. Updating through command line works correctly. I use hudson 1.352, subversion 1.15.

        Show
        kocar kocar added a comment - In my case the external folders are not created at all... The directory "!depend", which has svn:externals property set, has no subdirectories. Updating through command line works correctly. I use hudson 1.352, subversion 1.15.
        Hide
        kbatra kbatra added a comment -

        The problem still exists in Hudson 1.354. Can someone please fix this? SVN-externaling is a cool feature, and I would very much like to see it fully supported in Hudson.

        Show
        kbatra kbatra added a comment - The problem still exists in Hudson 1.354. Can someone please fix this? SVN-externaling is a cool feature, and I would very much like to see it fully supported in Hudson.
        Hide
        larsheinemann larsheinemann added a comment -

        Is there any workaround?

        Show
        larsheinemann larsheinemann added a comment - Is there any workaround?
        Hide
        kocar kocar added a comment -

        We use it with maven2 projects, so I set the goal to

        scm:update install

        It works correctly...

        Show
        kocar kocar added a comment - We use it with maven2 projects, so I set the goal to scm:update install It works correctly...
        Hide
        ciresh ciresh added a comment -

        Had this problem when we had externals to two different repositories. All the externals from the repository that the main code was located on came down. None of the files for the other repository came down and there where no errors or warnings. After entering credentials for the second repository everything come down. You can try the following url to enter the svn credentials:

        http://MyHudsonURL/scm/SubversionSCM/enterCredential

        Show
        ciresh ciresh added a comment - Had this problem when we had externals to two different repositories. All the externals from the repository that the main code was located on came down. None of the files for the other repository came down and there where no errors or warnings. After entering credentials for the second repository everything come down. You can try the following url to enter the svn credentials: http://MyHudsonURL/scm/SubversionSCM/enterCredential
        Hide
        kohsuke Kohsuke Kawaguchi added a comment -

        So the problem here is that Hudson is failing to report a failure to checkout repositories referenced by svn:external?

        Show
        kohsuke Kohsuke Kawaguchi added a comment - So the problem here is that Hudson is failing to report a failure to checkout repositories referenced by svn:external?
        Hide
        abarbieri Andrea Barbieri added a comment -

        most likely this is very similar to this reported problem:
        http://issues.jenkins-ci.org/browse/JENKINS-6415

        Show
        abarbieri Andrea Barbieri added a comment - most likely this is very similar to this reported problem: http://issues.jenkins-ci.org/browse/JENKINS-6415
        Hide
        larsheinemann larsheinemann added a comment -

        In our case, the problem is that the external files are not checked out.

        Show
        larsheinemann larsheinemann added a comment - In our case, the problem is that the external files are not checked out.
        Hide
        uresu uresu added a comment - - edited

        I solved my occurence of this issue. When looking at the details of the svn:externals property, they were set to a server that the Hudson server could not resolve

        Show
        uresu uresu added a comment - - edited I solved my occurence of this issue. When looking at the details of the svn:externals property, they were set to a server that the Hudson server could not resolve
        Hide
        veita veita added a comment -

        Same problem here with Hudson 1.366.

        A directory that has a relative svn:externals link to a file (../../../../../../../../a/b/c/d/e/f/g/my.cfg my.cfg) is empty after svn-update in Hudson.

        Creating a copy of the linked resources is not a solution for us. They must always be up-to-date in the modules that contain tests that require these files and directories.

        Show
        veita veita added a comment - Same problem here with Hudson 1.366. A directory that has a relative svn:externals link to a file (../../../../../../../../a/b/c/d/e/f/g/my.cfg my.cfg) is empty after svn-update in Hudson. Creating a copy of the linked resources is not a solution for us. They must always be up-to-date in the modules that contain tests that require these files and directories.
        Hide
        maartenvandewaarsenburg maartenvandewaarsenburg added a comment -

        Just an observation. I hope it helps as this is a serious problem.

        On a directory in a subtree of the trunk of a project I have the following svn:externals property set:

        /svn/partslib/Arabica/2009-march-xerces_2.8.0-Verum/VS90 Arabica
        /svn/partslib/formalsystems/noxfdr/3.0.0/client FDR
        /svn/partslib/opensource/boost-uuid/20080225/ boost/uuid
        /svn/partslib/xerces/xerces-c/2.8.0/vs90 xercesc
        /svn/partslib/nokia/Qt/4.6.3/vs90 Qt

        When I perform a clean build of the Hudson project (subtree), it checks out all except the last one. Every clean build, the same external is skipped. A subsequent build with "Use update" checked, checks out the missing external.

        When I change the Hudson project to check out the entire trunk, a clean build checks out all except the one BEFORE the last line.

        It doesn't matter on what kind of slave the project builds.

        Hudson ver. 1.361
        Hudson Subversion Plug-in 1.17
        svnkit-1.3.0-hudson-4.jar
        Windows slave running via JNLP
        Red Hat slave running via SSH (plugin version 0.12)
        VisualSVN 2.1.1

        Question: The svnkit has hudson in its name, does that mean that the svnkit is adapted to work with Hudson? In other words, can I replace the JAR-file by a more recent version of tmatesoft?

        Show
        maartenvandewaarsenburg maartenvandewaarsenburg added a comment - Just an observation. I hope it helps as this is a serious problem. On a directory in a subtree of the trunk of a project I have the following svn:externals property set: /svn/partslib/Arabica/2009-march-xerces_2.8.0-Verum/VS90 Arabica /svn/partslib/formalsystems/noxfdr/3.0.0/client FDR /svn/partslib/opensource/boost-uuid/20080225/ boost/uuid /svn/partslib/xerces/xerces-c/2.8.0/vs90 xercesc /svn/partslib/nokia/Qt/4.6.3/vs90 Qt When I perform a clean build of the Hudson project (subtree), it checks out all except the last one. Every clean build, the same external is skipped. A subsequent build with "Use update" checked, checks out the missing external. When I change the Hudson project to check out the entire trunk, a clean build checks out all except the one BEFORE the last line. It doesn't matter on what kind of slave the project builds. Hudson ver. 1.361 Hudson Subversion Plug-in 1.17 svnkit-1.3.0-hudson-4.jar Windows slave running via JNLP Red Hat slave running via SSH (plugin version 0.12) VisualSVN 2.1.1 Question: The svnkit has hudson in its name, does that mean that the svnkit is adapted to work with Hudson? In other words, can I replace the JAR-file by a more recent version of tmatesoft?

          People

          • Assignee:
            Unassigned
            Reporter:
            larsheinemann larsheinemann
          • Votes:
            11 Vote for this issue
            Watchers:
            12 Start watching this issue

            Dates

            • Created:
              Updated: