您能否提供更多细节？确切地说，此文件是什么？为什么要在Jenkins构建中将其提交？您正在构建什么（Java？C ++ ？. NET？），以及如何构建它？

通常，除了 源
文件之外，您不应将任何东西置于版本控制之下。也就是说，如果可以构建它，则不应将其放入版本控制中。很多人喜欢将其内置代码提交到版本控制系统中，但这通常是一个大错误。二进制文件更大，并且很少差异。这将导致源存储库的编译代码达到90％－几乎所有代码都已过时。对于Subversion来说，这尤其成问题，因为Subversion无法（轻松地）删除过时的代码。

詹金斯（Jenkins）具有一项功能，可让您 存档生成
的文件以便于访问。我们一直在使用它。我们构建了代码，该程序可在Jenkins中下载。更好的是，Jenkins将删除较早的版本（您可以保存最近的X个版本，或者仅保存X天以下的版本）。并且，如果您有候选发布版本，则可以
锁定 该版本以防止其被删除。

但是，如果您坚持要这样做，则有几件事可以做，并且需要注意：

1. 当您设置了Jenkins来自动构建每个更改，并且在版本控制系统中提交了更改时，Jenkins将会看到并开始新的构建。然后，詹金斯保存更改，查看更改，然后进行另一次构建。确保应该在进行构建时从Jenkins的考虑中排除文件或目录。您可以在指定结帐的URL时指定它。

2. 与大多数版本控制系统不同，Subversion是独立于客户端的。有一个针对客户的实际API。Jenkins不需要标准的Subversion命令行客户端，因此请确保已安装。确保安装与SVNKit客户端内置的Jenkins兼容的客户端。由于Subversion 1.6、1.7和1.8均采用不同的客户端格式，因此尤其如此。

3. 您可以在Jenkins中向您的构建添加多个 构建步骤 。只需添加一个新的Shell脚本或批处理脚本步骤，然后添加一个svn commit -m "comment of some sort"步骤。处理完前两点后，这很简单。但是，请仔细考虑为什么要这样做。

就像我之前说的，在99.9999％的时间中，您不应该使用Jenkins来提交它构建的更改。我确定 某个地方
存在0.0001％的原因，但我从未见过。如果要使其他项目可以通用访问构建文件，请使用Jenkin的功能来存档构建文件。

如果另一个构建需要Jenkins正在构建的产品，则可以使用“ 复制工件”插件将构建工件复制到另一个作业，然后启动该作业。更好的是，使用发布存储库系统。在Java中，您可以使用Nexus或Artifactory之类的Maven发布存储库。要使用工件并将其部署到该存储库，可以使用Ivy或Maven或Gradle。如果要构建.NET，请查看Nuget。