jenkinsci / jenkinsci/subversion-plugin

[JENKINS-27898] Change Subversion plugin to allow configuration of different ways to react to working copy locked

Open
#1,264 2 comments 0 reactions 0 assignees View on GitHub
component:subversion-plugin imported-jira-issue priority:major resolution:unresolved
Dominant language
Java
Stars
131
Forks
275
Avg merge
12h 4m
Merged PRs (30d)
6

Description

The Jenkins job/build immediately fails if the working copy is locked. For me, this is undesirable due to the structure of our repository. We have multiple builds trying to update their individual portions of the working copy. Unfortunately, svn locks the working copy one directory above the one in which the update occurs, so we get failures if multiple builds are triggered concurrently, even though they are in different sections of the repository. The way it currently works, we are notifying commiters that they have a build failure even though the changes themselves did not cause the failure, and then if they have nothing more to commit there is no choice but to MANUALLY trigger the job again.

I would much prefer to have this be configurable. Let me decide if I want it to fail (current behavior), or try again every ___ seconds with ___ total attempts, other...

---
Originally reported by tpbradt, imported from: Change Subversion plugin to allow configuration of different ways to react to working copy locked


  • status: Open
  • priority: Major
  • component(s): subversion-plugin
  • resolution: Unresolved
  • votes: 0
  • watchers: 2
  • imported: 20251212-090250

Raw content of original issue

The Jenkins job/build immediately fails if the working copy is locked. For me, this is undesirable due to the structure of our repository. We have multiple builds trying to update their individual portions of the working copy. Unfortunately, svn locks the working copy one directory above the one in which the update occurs, so we get failures if multiple builds are triggered concurrently, even though they are in different sections of the repository. The way it currently works, we are notifying commiters that they have a build failure even though the changes themselves did not cause the failure, and then if they have nothing more to commit there is no choice but to MANUALLY trigger the job again.

I would much prefer to have this be configurable. Let me decide if I want it to fail (current behavior), or try again every ___ seconds with ___ total attempts, other...

environment

```
Windows Server 2012 R2

Jenkins v1.573

Subversion Plug-in v2.5

Chrome
```

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.