Can you give some details? Exactly what is this file, and why should it be committed as part of your Jenkins build? What are you building (Java? C ++?. NET?) And how do you create it?
Usually you should not put anything under version control other than the source files. That is, if you can build it, you should not introduce it into version control. Many people like to pass their embedded code into their version control system, but this is usually a big mistake. binary files are much larger and rarely different. This leads to the original repository, which makes up 90% of the compiled code - almost all of this is deprecated. This is especially problematic for Subversion, which does not have the ability to (easily) remove obsolete code.
Jenkins has a feature that allows you to archive your embedded files for easy access. We use it all the time. We create our code and the program is available in Jenkins for download. Even better, Jenkins will remove old assemblies (you can save the latest builds of X or save only assemblies younger than X days). And if you have a release release build, you can lock that build to prevent it from being deleted.
However, if you insist on this, there are a few things you can do, and things you must observe:
When you have Jenkins set up to automatically create each change, and you make changes to your version control system, Jenkins will see this and start a new build. Jenkins then saves the changes, sees the changes, and makes another build. Make sure you exclude files or directories from Jenkins considerations when they should build. You can specify this when you provide the validation URL.
Unlike most version control systems, Subversion was client independent. There is a real API for clients. A standard Subversion command line client is not needed in Jenkins, so make sure it is installed. Make sure you install the Jenkins compatible client built into the SVNKit client. This is especially true since Subversion 1.6, 1.7, and 1.8 all accept a different client format.
You can add several assembly steps to your assembly in Jenkins. Just add a new shell script or batch script step and add the step svn commit -m "comment of some sort" . This is quite simple to do if you have taken care of the first two points. However, please consider why you are doing this.
As I said, 99.9999% of the time, you should not use Jenkins to commit the changes that he created. I am sure that the reason 0.0001% exists somewhere, but I have never seen it. If you want to make embedded files universal for other projects, use Jenkin's ability to archive created files.
If you need a Jenkins product to create another assembly, you can use Copy Artifact Plugin to copy the assembly artifact to another task, and then burn this work. Better yet, use the release repository system. In Java, you can use the Maven release repository, such as Nexus or Artifactory. To use and deploy artifacts in this repository, you can use Ivy or Maven or Gradle. If you are creating .NET, look at Nuget.