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.

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.

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

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.

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

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

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.

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...

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?

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.

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.

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.

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...

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.

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

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.

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.

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.

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

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

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?

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.