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

Add a "Use Export" option to the Subversion config section of a job

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

      It would be great to have a "Use Export" option on the Subversion configuration
      section of a job, similar to the current "Use Update" option.
      This greatly speeds up the checkout time for a build.

      The feature is applicable when:
      1. Your project does not have a reliable clean or rebuild setup, or you
      absolutely want to start with a clean workspace for every build.
      2. You project does not expect to perform any working copy subversion
      operations as part of the build.

      We made a quick hack to test the approach by changing the source to use
      "checkout" for only the root module directory (no recursion), and then "export"
      the module with full recursion. The change dropped our checkout time from 31 to
      11 minutes. The approach we coded was not very clean. It would probably be
      better to run only the "export" command and use the returned revision number to
      obtain the necessary SVNInfo object from the server instead of the working copy
      (for change log and tagging purposes).

          [JENKINS-1304] Add a "Use Export" option to the Subversion config section of a job

          Hi!

          What about this request? Will patch help to implement it faster? Or there is another issues about this request?

          Denis Nevmerzhitsky added a comment - Hi! What about this request? Will patch help to implement it faster? Or there is another issues about this request?

          The hard part with this, I'd think, is it'd be hard to do a poll without having the metadata there to know how old the environment was. I wouldn't if we can't use the poll feature, I'd just like the ability to not have to hard code a command line to do "svn export URL...." for my jobs that I don't want the .svn folders.

          Kendrick Martin added a comment - The hard part with this, I'd think, is it'd be hard to do a poll without having the metadata there to know how old the environment was. I wouldn't if we can't use the poll feature, I'd just like the ability to not have to hard code a command line to do "svn export URL...." for my jobs that I don't want the .svn folders.

          Shawn Baker added a comment -

          I'd think if you set up your project to Export, then you wouldn't be able to poll for changes. I'd like to have the option to export, as I use post-commit hooks to kick off my builds.

          Shawn Baker added a comment - I'd think if you set up your project to Export, then you wouldn't be able to poll for changes. I'd like to have the option to export, as I use post-commit hooks to kick off my builds.

          I would really like that feature. We are currently using a separate SVN repository for storing our release artifacts. We decided for SVN since it gives us audit compared to Nexus and it is already build into jenkins for checkout. In my use case we have a job that deploys to WAS. For that to work it actually runs on the server where the WAS is installed. Since every environment runs on a different was server, the same artifact will most likely not downloaded twice to the same server. This said, we need to download a new version for every deployment anyway. The folder that gets checked out is currently 1.3 GB where some of the deploy jobs need only one or two artifacts which are less then 50MB. So the export function would help tremendously in cutting down disk space and deployment time. As stated before update is not a concern since almost always the new version of the artifacts need to be downloaded anyway. History is not a concern either since the history is tied to the source code that is stored in a separate repo. Installing a svn client on all WAS servers is currently not an option since we haven't looked into installing a svn client on AIX yet.

          Long story short:

          • Export would be beneficial for 2 reasons
            • save space
            • save time
          • Export should have the option to download only a single file

          peter_schuetze added a comment - I would really like that feature. We are currently using a separate SVN repository for storing our release artifacts. We decided for SVN since it gives us audit compared to Nexus and it is already build into jenkins for checkout. In my use case we have a job that deploys to WAS. For that to work it actually runs on the server where the WAS is installed. Since every environment runs on a different was server, the same artifact will most likely not downloaded twice to the same server. This said, we need to download a new version for every deployment anyway. The folder that gets checked out is currently 1.3 GB where some of the deploy jobs need only one or two artifacts which are less then 50MB. So the export function would help tremendously in cutting down disk space and deployment time. As stated before update is not a concern since almost always the new version of the artifacts need to be downloaded anyway. History is not a concern either since the history is tied to the source code that is stored in a separate repo. Installing a svn client on all WAS servers is currently not an option since we haven't looked into installing a svn client on AIX yet. Long story short: Export would be beneficial for 2 reasons save space save time Export should have the option to download only a single file

          elygre added a comment -

          I would love this. We use "Always check out a clean copy" for a nightly build, and for that build this would be very useful. This build don't use the "poll for changes" functionality, so this is not a loss. Also, since this is always a clean copy, the pristine svn-files are absolutely wasteful.

          Reading old mailing list threads (such as https://groups.google.com/forum/#!topic/jenkinsci-users/1eN74vwtpcs), there seem to be an understanding that an "export" option is less good than an "update". That is probably true. However, compared to an "Always check out a clean copy", "export" is plain better

          elygre added a comment - I would love this. We use "Always check out a clean copy" for a nightly build, and for that build this would be very useful. This build don't use the "poll for changes" functionality, so this is not a loss. Also, since this is always a clean copy, the pristine svn-files are absolutely wasteful. Reading old mailing list threads (such as https://groups.google.com/forum/#!topic/jenkinsci-users/1eN74vwtpcs ), there seem to be an understanding that an "export" option is less good than an "update". That is probably true. However, compared to an "Always check out a clean copy", "export" is plain better

          Boaz Barda added a comment -

          Is this long forgotten?
          there should be an easy way to export and NOT loose the metadata for the changeset etc.

          Boaz Barda added a comment - Is this long forgotten? there should be an easy way to export and NOT loose the metadata for the changeset etc.

          +1
          it will be useful

          Aleksandr Borovkov added a comment - +1 it will be useful

          Alex Vesely added a comment -

          This would be perfect for my use-case as well. I always use a clean checkout, so "export" would save time, space and network bandwidth compared to "checkout".

          Alex Vesely added a comment - This would be perfect for my use-case as well. I always use a clean checkout, so "export" would save time, space and network bandwidth compared to "checkout".

          karan dave added a comment -

          +1

          it is very useful feature to have

           

          karan dave added a comment - +1 it is very useful feature to have  

          Andrew Marlow added a comment -

          This is a useful feature to have for projects that have to be scanned using Black Duck. This is because Black Duck needs to be presented with a mixture of source and built artifacts and there is a size limit on the directory that is presented. This size can be quite large when it includes all the .svn directories. It would be nice to export so those directories are absent. It helps to keep things under the Black Duck limit.

          Andrew Marlow added a comment - This is a useful feature to have for projects that have to be scanned using Black Duck. This is because Black Duck needs to be presented with a mixture of source and built artifacts and there is a size limit on the directory that is presented. This size can be quite large when it includes all the .svn directories. It would be nice to export so those directories are absent. It helps to keep things under the Black Duck limit.

            Unassigned Unassigned
            avanha avanha
            Votes:
            28 Vote for this issue
            Watchers:
            19 Start watching this issue

              Created:
              Updated: