Details

    • Similar Issues:

      Description

      When updating the 'stable' builds of our projects, I update the repository URL
      from svn://aaa/project/branches/182 to svn://aaa/project/branches/183 ( for
      instance ).

      This results in a clean checkout ( Checking out a fresh workspace because the
      workspace is not svn://aaa/project/branches/183 ), which takes somewhere around
      30 minutes, when a svn switch would've taken a few seconds.

      What I suggest is a (perhaps per job configurable) setting which would use svn
      switch if all but the last

      {x}

      path elements are the same.

      For instance, a setting of 1 would allow switch to be used for

      svn://aaa/project/branches/183 -> svn://aaa/project/branches/184

      but not for

      svn://aaa/project/branches/183 -> svn://aaa/project/trunk

      A setting of 2 would allow switch to be used for both.

      A setting of 0 would disallow the usage of svn switch.

        Attachments

        1. subversion.diff
          12 kB
        2. subversion2.diff
          10 kB
        3. subversion3.diff
          11 kB

          Issue Links

            Activity

            Hide
            mschemmel mschemmel added a comment -

            This would be extremely useful, even if it were as simple as
            [x] Use switch
            [ ] Use update

            in the configuration of each job.

            Parameterized builds for testing individual feature workspaces, which generally change a minimal number of the artifacts in the repository, take far longer than necessary due to the need to retrieve a largish repository before beginning each build.

            The "development testing" Hudson jobs we use do not cause any artifacts to be committed back to the repository, so there is no danger of merge conflicts through local modifications... the ability to select 'switch' vs 'update' on a per-job basis would greatly magnify the utility enabled by the tool.

            Show
            mschemmel mschemmel added a comment - This would be extremely useful, even if it were as simple as [x] Use switch [ ] Use update in the configuration of each job. Parameterized builds for testing individual feature workspaces, which generally change a minimal number of the artifacts in the repository, take far longer than necessary due to the need to retrieve a largish repository before beginning each build. The "development testing" Hudson jobs we use do not cause any artifacts to be committed back to the repository, so there is no danger of merge conflicts through local modifications... the ability to select 'switch' vs 'update' on a per-job basis would greatly magnify the utility enabled by the tool.
            Hide
            ymajoros ymajoros added a comment -

            I also think this would be very good. We use to tag our builds as TEST or PROD, so we know this tagged version is what is going to TEST/PROD.

            In order to do that, I always have to:

            • disable hudson job for the TEST or PROD task
            • remove the old TEST or PROD tag (svn remove)
            • create a new tag (usually, svn copy from dev branch)
            • go to job build directory and manually run svn switch
            • enable hudson job again

            Enabling hudson to switch would really be a good thing.

            Show
            ymajoros ymajoros added a comment - I also think this would be very good. We use to tag our builds as TEST or PROD, so we know this tagged version is what is going to TEST/PROD. In order to do that, I always have to: disable hudson job for the TEST or PROD task remove the old TEST or PROD tag (svn remove) create a new tag (usually, svn copy from dev branch) go to job build directory and manually run svn switch enable hudson job again Enabling hudson to switch would really be a good thing.
            Hide
            samodelkin samodelkin added a comment -

            Attached patch implements "Switch" option for "Update".

            Show
            samodelkin samodelkin added a comment - Attached patch implements "Switch" option for "Update".
            Hide
            kohsuke Kohsuke Kawaguchi added a comment -

            Thank you for the patch, and my apologies for the delay.

            In Hudson, we try hard to avoid providing too many switches, and I'm afraid this change doesn't pass that test.

            My proposal is to look at the SVNInfo.getRepositoryRootURL() to determine if the current checked-out copy and the checkout URL shares the same repository root, and if so, use "svn switch" instead of full-blown "svn checkout" in IsUpdatableTask.

            In this way, no user configuration is necessary.

            Show
            kohsuke Kohsuke Kawaguchi added a comment - Thank you for the patch, and my apologies for the delay. In Hudson, we try hard to avoid providing too many switches, and I'm afraid this change doesn't pass that test. My proposal is to look at the SVNInfo.getRepositoryRootURL() to determine if the current checked-out copy and the checkout URL shares the same repository root, and if so, use "svn switch" instead of full-blown "svn checkout" in IsUpdatableTask. In this way, no user configuration is necessary.
            Hide
            samodelkin samodelkin added a comment -

            Attached patch implements "svn switch" when doing update if repository root is not changed.

            Show
            samodelkin samodelkin added a comment - Attached patch implements "svn switch" when doing update if repository root is not changed.
            Hide
            samodelkin samodelkin added a comment -

            subversion2.diff is incorrect. The following error happens when matrix project is built:

            Started by upstream project "platform-release-build" build number 28
            Building remotely on qa-poa-as4-x86
            hudson.util.IOException2: remote file operation failed: /home/buildbot/hudson/workspace/platform-release-build/label/qa-poa-as4-x86 at hudson.remoting.Channel@380dc55c:qa-poa-as4-x86
            at hudson.FilePath.act(FilePath.java:749)
            at hudson.FilePath.act(FilePath.java:735)
            at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:597)
            at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:544)
            at hudson.model.AbstractProject.checkout(AbstractProject.java:1044)
            at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:479)
            at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:411)
            at hudson.model.Run.run(Run.java:1257)
            at hudson.matrix.MatrixRun.run(MatrixRun.java:130)
            at hudson.model.ResourceController.execute(ResourceController.java:88)
            at hudson.model.Executor.run(Executor.java:127)
            Caused by: java.io.IOException: Unable to serialize hudson.FilePath$FileCallableWrapper@77fc501e
            at hudson.remoting.UserRequest.serialize(UserRequest.java:162)
            at hudson.remoting.UserRequest.<init>(UserRequest.java:62)
            at hudson.remoting.Channel.call(Channel.java:554)
            at hudson.FilePath.act(FilePath.java:742)
            ... 10 more
            Caused by: java.io.NotSerializableException: hudson.matrix.MatrixConfiguration
            at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1156)
            at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1509)
            at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1474)
            at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392)
            at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
            at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1509)
            at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1474)
            at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392)
            at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
            at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326)
            at hudson.remoting.UserRequest._serialize(UserRequest.java:151)
            at hudson.remoting.UserRequest.serialize(UserRequest.java:160)
            ... 13 more

            Fixed version is attached

            Show
            samodelkin samodelkin added a comment - subversion2.diff is incorrect. The following error happens when matrix project is built: Started by upstream project "platform-release-build" build number 28 Building remotely on qa-poa-as4-x86 hudson.util.IOException2: remote file operation failed: /home/buildbot/hudson/workspace/platform-release-build/label/qa-poa-as4-x86 at hudson.remoting.Channel@380dc55c:qa-poa-as4-x86 at hudson.FilePath.act(FilePath.java:749) at hudson.FilePath.act(FilePath.java:735) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:597) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:544) at hudson.model.AbstractProject.checkout(AbstractProject.java:1044) at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:479) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:411) at hudson.model.Run.run(Run.java:1257) at hudson.matrix.MatrixRun.run(MatrixRun.java:130) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:127) Caused by: java.io.IOException: Unable to serialize hudson.FilePath$FileCallableWrapper@77fc501e at hudson.remoting.UserRequest.serialize(UserRequest.java:162) at hudson.remoting.UserRequest.<init>(UserRequest.java:62) at hudson.remoting.Channel.call(Channel.java:554) at hudson.FilePath.act(FilePath.java:742) ... 10 more Caused by: java.io.NotSerializableException: hudson.matrix.MatrixConfiguration at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1156) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1509) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1474) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1509) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1474) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326) at hudson.remoting.UserRequest._serialize(UserRequest.java:151) at hudson.remoting.UserRequest.serialize(UserRequest.java:160) ... 13 more Fixed version is attached
            Hide
            djdevin Devin Zuczek added a comment -

            Our jenkins set up would be perfect if not for this issue. We have a very large repository and it takes forever to clean and re-checkout. When we prepare a release for testing, it's tagged and then svn switched to the proper one. For this reason some of our workspaces are set up manually and don't use the built in jenkins SCM integration.

            I've tried to use the patches against the current subversion plugin code, but there were too many changes in the affected areas to apply cleanly.

            Show
            djdevin Devin Zuczek added a comment - Our jenkins set up would be perfect if not for this issue. We have a very large repository and it takes forever to clean and re-checkout. When we prepare a release for testing, it's tagged and then svn switched to the proper one. For this reason some of our workspaces are set up manually and don't use the built in jenkins SCM integration. I've tried to use the patches against the current subversion plugin code, but there were too many changes in the affected areas to apply cleanly.
            Hide
            salmira Tetiana Tvardovska added a comment -

            We also have to do manual switch on production to other branches, so this feature would incredibly useful!
            For our project, svn checkout takes more than 40 minutes, that is too long...

            Show
            salmira Tetiana Tvardovska added a comment - We also have to do manual switch on production to other branches, so this feature would incredibly useful! For our project, svn checkout takes more than 40 minutes, that is too long...
            Hide
            mattdoran Matt Doran added a comment -

            This also causes us problems. I noticed that JENKINS-11086 was recently closed by Koshuke saying this could be implemented by checking repository UUIDs, which I assume is what the patch above did.

            Koshuke, is the above approach suitable? If this patch were fixed to apply cleanly could it be applied?

            Show
            mattdoran Matt Doran added a comment - This also causes us problems. I noticed that JENKINS-11086 was recently closed by Koshuke saying this could be implemented by checking repository UUIDs, which I assume is what the patch above did. Koshuke, is the above approach suitable? If this patch were fixed to apply cleanly could it be applied?
            Hide
            javasuperman Steven Lee added a comment -

            Just ran into this too and it takes way too long to delete everything and then check it out again.

            We have a large amount of static files (mp3, mov, etc.) in subversion which are deployed to apache.

            Show
            javasuperman Steven Lee added a comment - Just ran into this too and it takes way too long to delete everything and then check it out again. We have a large amount of static files (mp3, mov, etc.) in subversion which are deployed to apache.
            Hide
            josh_holding Josh Holding added a comment -

            I'm surprised this issue is so old and not resolved yet. We just started using Jenkins not too long ago and ran into this right away. Would be great to have this fixed.

            Show
            josh_holding Josh Holding added a comment - I'm surprised this issue is so old and not resolved yet. We just started using Jenkins not too long ago and ran into this right away. Would be great to have this fixed.
            Hide
            damienfinck67 Damien Finck added a comment -

            We have this problem too, we currently have to manualy switch the repo and then cascade the changes in the configuration.
            This is error-prone and not practical.

            Show
            damienfinck67 Damien Finck added a comment - We have this problem too, we currently have to manualy switch the repo and then cascade the changes in the configuration. This is error-prone and not practical.
            Hide
            elkangaroo Alexander Wenzel added a comment -

            Having jenkins use 'svn switch' instead of a full checkout when changing the branch of the project would be heavily appreciated.
            This would save a lot of time, if you have a lot of files in the repository.

            +1 for a fix for this 4 years old issue...

            Show
            elkangaroo Alexander Wenzel added a comment - Having jenkins use 'svn switch' instead of a full checkout when changing the branch of the project would be heavily appreciated. This would save a lot of time, if you have a lot of files in the repository. +1 for a fix for this 4 years old issue...
            Hide
            kutzi kutzi added a comment -

            Could someone (preferably the one submitting the patch) check if the patch can still be applied without conflicts and convert it to a Github pull request?
            Then I'll have a look at it - when time allows.

            Show
            kutzi kutzi added a comment - Could someone (preferably the one submitting the patch) check if the patch can still be applied without conflicts and convert it to a Github pull request? Then I'll have a look at it - when time allows.
            Hide
            petdr Peter Ross added a comment -

            See pull request https://github.com/jenkinsci/subversion-plugin/pull/34

            My code looks for changes like branches/a to branches/b, or branches/a to trunk, or trunk to branches/a.

            Show
            petdr Peter Ross added a comment - See pull request https://github.com/jenkinsci/subversion-plugin/pull/34 My code looks for changes like branches/a to branches/b, or branches/a to trunk, or trunk to branches/a.
            Hide
            petdr Peter Ross added a comment -

            After review from kutzi see pull request https://github.com/jenkinsci/subversion-plugin/pull/35

            Show
            petdr Peter Ross added a comment - After review from kutzi see pull request https://github.com/jenkinsci/subversion-plugin/pull/35
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: peter
            Path:
            src/main/java/hudson/scm/subversion/UpdateUpdater.java
            http://jenkins-ci.org/commit/subversion-plugin/520b99380895e1768f7a8b2270b3e3fea41e64a5
            Log:
            JENKINS-2556 Detect when a "svn switch" can be used rather than a "svn checkout" in the UpdateUpdater.

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: peter Path: src/main/java/hudson/scm/subversion/UpdateUpdater.java http://jenkins-ci.org/commit/subversion-plugin/520b99380895e1768f7a8b2270b3e3fea41e64a5 Log: JENKINS-2556 Detect when a "svn switch" can be used rather than a "svn checkout" in the UpdateUpdater.
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: Christoph Kutzinski
            Path:
            src/main/java/hudson/scm/subversion/UpdateUpdater.java
            http://jenkins-ci.org/commit/subversion-plugin/6f3538ce695914395c3080741e117da0ff444ef3
            Log:
            Merge pull request #35 from petdr/jenkins_2556

            [FIXED JENKINS-2556] Use "svn switch" rather than a "svn checkout" if applicable

            Compare: https://github.com/jenkinsci/subversion-plugin/compare/d0cb4fa7bc48...6f3538ce6959


            You received this message because you are subscribed to the Google Groups "Jenkins Commits" group.
            To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-commits+unsubscribe@googlegroups.com.
            For more options, visit https://groups.google.com/groups/opt_out.

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Christoph Kutzinski Path: src/main/java/hudson/scm/subversion/UpdateUpdater.java http://jenkins-ci.org/commit/subversion-plugin/6f3538ce695914395c3080741e117da0ff444ef3 Log: Merge pull request #35 from petdr/jenkins_2556 [FIXED JENKINS-2556] Use "svn switch" rather than a "svn checkout" if applicable Compare: https://github.com/jenkinsci/subversion-plugin/compare/d0cb4fa7bc48...6f3538ce6959 – You received this message because you are subscribed to the Google Groups "Jenkins Commits" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-commits+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out .
            Hide
            jglick Jesse Glick added a comment -

            For the record: a user of the 1.45 plugin who was encountering unexplained errors such as

            Building remotely on … in workspace …\workspace\…job…
            Checking out a fresh workspace because there's no workspace at …\workspace\…job…\SRC
            Cleaning local Directory SRC
            hudson.util.IOException2: remote file operation failed: …\workspace\…job… at hudson.remoting.Channel@…:…
                at hudson.FilePath.act(FilePath.java:861)
                at hudson.FilePath.act(FilePath.java:838)
                at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:843)
                at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:781)
                at hudson.model.AbstractProject.checkout(AbstractProject.java:1331)
                at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:682)
                at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
                at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:587)
                at hudson.model.Run.execute(Run.java:1557)
                at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
                at hudson.model.ResourceController.execute(ResourceController.java:88)
                at hudson.model.Executor.run(Executor.java:236)
            Caused by: java.io.IOException: Unable to delete …\workspace\…job…\SRC\…file…
                at hudson.Util.deleteFile(Util.java:243)
                at hudson.Util.deleteRecursive(Util.java:293)
                at hudson.Util.deleteContentsRecursive(Util.java:204)
                at hudson.scm.subversion.CheckoutUpdater$1.perform(CheckoutUpdater.java:75)
                at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:153)
                at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161)
                at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:121)
                at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:153)
                at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:903)
                at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:884)
                at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:867)
                at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2348)
                at hudson.remoting.UserRequest.perform(UserRequest.java:118)
                at hudson.remoting.UserRequest.perform(UserRequest.java:48)
                at hudson.remoting.Request$2.run(Request.java:326)
                at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
                at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
                at java.util.concurrent.FutureTask.run(Unknown Source)
                at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
                at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
                at java.lang.Thread.run(Unknown Source)
            

            reports that these issues disappear when using a build of the plugin incorporating this (JENKINS-2556) fix.

            Show
            jglick Jesse Glick added a comment - For the record: a user of the 1.45 plugin who was encountering unexplained errors such as Building remotely on … in workspace …\workspace\…job… Checking out a fresh workspace because there's no workspace at …\workspace\…job…\SRC Cleaning local Directory SRC hudson.util.IOException2: remote file operation failed: …\workspace\…job… at hudson.remoting.Channel@…:… at hudson.FilePath.act(FilePath.java:861) at hudson.FilePath.act(FilePath.java:838) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:843) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:781) at hudson.model.AbstractProject.checkout(AbstractProject.java:1331) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:682) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:587) at hudson.model.Run.execute(Run.java:1557) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:236) Caused by: java.io.IOException: Unable to delete …\workspace\…job…\SRC\…file… at hudson.Util.deleteFile(Util.java:243) at hudson.Util.deleteRecursive(Util.java:293) at hudson.Util.deleteContentsRecursive(Util.java:204) at hudson.scm.subversion.CheckoutUpdater$1.perform(CheckoutUpdater.java:75) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:153) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:121) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:153) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:903) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:884) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:867) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2348) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) reports that these issues disappear when using a build of the plugin incorporating this ( JENKINS-2556 ) fix.
            Hide
            mattdoran Matt Doran added a comment -

            Any thoughts pushing a new build of the SVN plugin that includes this fix?

            Show
            mattdoran Matt Doran added a comment - Any thoughts pushing a new build of the SVN plugin that includes this fix?
            Hide
            kutzi kutzi added a comment -

            After I've burned 2 release numbers because of a stupid maven bug (http://www.shredzone.de/cilla/page/373/maven-release-plugin-and-git-fix.html), I've released it as 1.48

            Show
            kutzi kutzi added a comment - After I've burned 2 release numbers because of a stupid maven bug ( http://www.shredzone.de/cilla/page/373/maven-release-plugin-and-git-fix.html ), I've released it as 1.48
            Hide
            anand_raju Anand Raju added a comment -

            Hello Kutzi,
            I am on Jenkins v1.546 and Jenkins Subversion Plugin v1.54. I still do not see the switch option when setting the checkout strategy in a new or pre-existing job. Is it only update which internally does switch as well when needed? or Is there any manual installation needed for SVN switch option to appear in the drop-down?

            Show
            anand_raju Anand Raju added a comment - Hello Kutzi, I am on Jenkins v1.546 and Jenkins Subversion Plugin v1.54. I still do not see the switch option when setting the checkout strategy in a new or pre-existing job. Is it only update which internally does switch as well when needed? or Is there any manual installation needed for SVN switch option to appear in the drop-down?
            Hide
            anand_raju Anand Raju added a comment -

            Hello Kutzi,
            I tested out the build and its automatically doing a switch when necessary. For others who have a similar confusion, it is the SVN update option under checkout strategy drop-down which performs a switch when applicable.

            Show
            anand_raju Anand Raju added a comment - Hello Kutzi, I tested out the build and its automatically doing a switch when necessary. For others who have a similar confusion, it is the SVN update option under checkout strategy drop-down which performs a switch when applicable.

              People

              • Assignee:
                kutzi kutzi
                Reporter:
                rombert Robert Munteanu
              • Votes:
                21 Vote for this issue
                Watchers:
                23 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: