• Icon: Improvement Improvement
    • Resolution: Fixed
    • Icon: Major Major
    • subversion-plugin
    • None
    • Platform: All, OS: All

      Hudson has a field for the Subversion Repository URL. This setting is used both
      for polling and for the actual checkout/update of files from the repository.
      This enhancement request is for these two svn operations to be decoupled so that
      Hudson can poll a repository location for changes without fetching the files
      from the server, or vice-versa.

      In our specific case we need to watch for changes in a tree that has > 1GB of
      data, but the triggered build will only need a small subtree. The build scripts
      contain logic to locate and fetch only what they need from beneath the
      repository path on their own.

      This request is specifically for subversion but could conceivably be expanded to
      most if not all SCM plugins.

          [JENKINS-2717] svn polling without checkout or update

          joe parelli added a comment -

          as pointed out in comments, this is not a duplicate issue. Many people have the necessity to poll SCM for changes and handle the checkout process in the scripts (fabric in my case)

          joe parelli added a comment - as pointed out in comments, this is not a duplicate issue. Many people have the necessity to poll SCM for changes and handle the checkout process in the scripts (fabric in my case)

          Oliver Merkel added a comment -

          joe parelli added a comment - 05/Sep/13 10:59 AM

          as pointed out in comments, this is not a duplicate issue. Many people have the necessity to poll SCM for changes and handle the checkout process in the scripts (fabric in my case)

          +1 (voted for the ticket -> upper right)

          Oliver Merkel added a comment - joe parelli added a comment - 05/Sep/13 10:59 AM as pointed out in comments, this is not a duplicate issue. Many people have the necessity to poll SCM for changes and handle the checkout process in the scripts (fabric in my case) +1 (voted for the ticket -> upper right)

          I'm having this issue as well, a fix would be just great.

          Fernando Devegili added a comment - I'm having this issue as well, a fix would be just great.

          Greg Hansen added a comment -

          I have a single parent project that gets a build number and queries Subversion for the head version, then passes these two values to 15 child processes (all of which work in parallel) that do their own checkouts, each at the same revision. I'd like to be able to trigger the parent project on an SCM change to the particular branch it's watching, without having to do the sync (which is about 7GB). Definitely NOT a duplicate.

          Greg Hansen added a comment - I have a single parent project that gets a build number and queries Subversion for the head version, then passes these two values to 15 child processes (all of which work in parallel) that do their own checkouts, each at the same revision. I'd like to be able to trigger the parent project on an SCM change to the particular branch it's watching, without having to do the sync (which is about 7GB). Definitely NOT a duplicate.

          Hemant Singh added a comment -

          I think this is must have feature for any complex system which uses Jenkins, please fix this issue.

          Hemant Singh added a comment - I think this is must have feature for any complex system which uses Jenkins, please fix this issue.

          This might be very useful in case of performing jobs triggered by update of the SVN repo. Some repositories may contains multiple project. Keeping workspace for all of them cause performance issue.

          Tomasz Majchrowski added a comment - This might be very useful in case of performing jobs triggered by update of the SVN repo. Some repositories may contains multiple project. Keeping workspace for all of them cause performance issue.

          Jesse Glick added a comment -

          Unless I am missing something, this is invalid in current plugin code. AbstractProject._poll first checks requiresWorkspaceForPolling. The implementation of this in SubversionSCM returns false unconditionally.

          (compareRemoteRevisionWith does include code to handle workspace != null, but it seems this will always in fact be null when called from _poll via SCM.poll…meaning that isPollFromMaster, setPollFromMaster, pollFromMaster, and POLL_FROM_MASTER are all dead code.)

          Jesse Glick added a comment - Unless I am missing something, this is invalid in current plugin code. AbstractProject._poll first checks requiresWorkspaceForPolling . The implementation of this in SubversionSCM returns false unconditionally. ( compareRemoteRevisionWith does include code to handle workspace != null , but it seems this will always in fact be null when called from _poll via SCM.poll …meaning that isPollFromMaster , setPollFromMaster , pollFromMaster , and POLL_FROM_MASTER are all dead code.)

          Jesse Glick added a comment -

          Let me amend that. In 2.4 and earlier, even though compareRemoteRevisionWith was being passed a null workspace (because it affirms it does not requiresWorkspaceForPolling), it nonetheless looked up the slave to run the last build and, if still online, did its polling from there! (Not in any particular working directory, and not locking the workspace, but on the same machine.) So it would have polled from the master despite doing checkouts on a slave only under some conditions: -Dhudson.scm.SubversionSCM.pollFromMaster was passed as a startup option; the slave has since been disconnected; all builds got deleted; etc.

          Now in 2.5, this change plus this correction mean that polling is unconditionally done on the master, and so the flags to control that are dead code, and CompareAgainstBaselineCallable is passed to a LocalChannel which calls it directly. Thus the issue of polling without requiring a slave was fixed inadvertently.

          The question remains whether the change was desirable or not. Generally it is cheaper and better to do polling from the master. There are however uncommon reasons why you might want to poll on a slave, for example: the master has no physical access to the Subversion server due to network topology; Subversion credentials are kept in ~/.subversion/auth/ only on slaves, not using the Credentials plugin. Perhaps the ability to poll from the slave ought to be reintroduced, ideally as a per-job UI option. (requiresWorkspaceForPolling probably needs to remain off, since it is not necessary to lock the workspace to poll, merely to run from the same machine and user account.)

          Anyway, rereading the original description of this issue, it was about something else entirely: the ability to use the Jenkins plugin only for polling, but performing actual checkout operations from the job’s build script. This is simply not supported in Jenkins generally, not the fault of the Subversion plugin.

          Jesse Glick added a comment - Let me amend that. In 2.4 and earlier, even though compareRemoteRevisionWith was being passed a null workspace (because it affirms it does not requiresWorkspaceForPolling ), it nonetheless looked up the slave to run the last build and, if still online, did its polling from there! (Not in any particular working directory, and not locking the workspace, but on the same machine.) So it would have polled from the master despite doing checkouts on a slave only under some conditions: -Dhudson.scm.SubversionSCM.pollFromMaster was passed as a startup option; the slave has since been disconnected; all builds got deleted; etc. Now in 2.5, this change plus this correction mean that polling is unconditionally done on the master, and so the flags to control that are dead code, and CompareAgainstBaselineCallable is passed to a LocalChannel which calls it directly. Thus the issue of polling without requiring a slave was fixed inadvertently. The question remains whether the change was desirable or not. Generally it is cheaper and better to do polling from the master. There are however uncommon reasons why you might want to poll on a slave, for example: the master has no physical access to the Subversion server due to network topology; Subversion credentials are kept in ~/.subversion/auth/ only on slaves, not using the Credentials plugin. Perhaps the ability to poll from the slave ought to be reintroduced, ideally as a per-job UI option. ( requiresWorkspaceForPolling probably needs to remain off, since it is not necessary to lock the workspace to poll, merely to run from the same machine and user account.) Anyway, rereading the original description of this issue, it was about something else entirely: the ability to use the Jenkins plugin only for polling, but performing actual checkout operations from the job’s build script. This is simply not supported in Jenkins generally, not the fault of the Subversion plugin.

          Vasili Galka added a comment -

          Proposed solution:
          Use svn update with non-sticky depth "empty". This does not really update the files/folders in the working copy as desired.
          However, Jenkins does not currently support non-sticky depth settings (I implemented it, see JENKINS-30141).

          Vasili Galka added a comment - Proposed solution: Use svn update with non-sticky depth "empty". This does not really update the files/folders in the working copy as desired. However, Jenkins does not currently support non-sticky depth settings (I implemented it, see JENKINS-30141 ).

          Moisei Rabinovich added a comment - - edited

          I've implemented another solution for this issue: add update strategy that does not touch working copy. And working copy can be update from pre-scm-build step implemented by  pre-scm-buildstep plugin.

          Here is the implementation: https://github.com/moisei/subversion-plugin/tree/noopupdater

          I am submitting pull request.

          Moisei Rabinovich added a comment - - edited I've implemented another solution for this issue: add update strategy that does not touch working copy. And working copy can be update from pre-scm-build step implemented by   pre-scm-buildstep  plugin. Here is the implementation: https://github.com/moisei/subversion-plugin/tree/noopupdater I am submitting pull request.

            Unassigned Unassigned
            andrewgoktepe Andrew Goktepe
            Votes:
            23 Vote for this issue
            Watchers:
            24 Start watching this issue

              Created:
              Updated:
              Resolved: