-
Bug
-
Resolution: Unresolved
-
Critical
-
None
Normally, when a locked working copy state is detected (e.g. because the previous build was interrupted during checkout), subversion scm will remove the working copy and does a fresh check out.
This does not work when the lock is in a working copy (svn:external) sub directory entry. The update of the external will simply be skipped and the working copy will stay in locked state.
I just realised that I recently commented JENKINS-7009 which might be the same/similar issue.
- is duplicated by
-
JENKINS-64084 Subversion update ignores locked workspace on windows
-
- Closed
-
- links to
This issue can cause a strange build behavior when using the "emulate clean checkout" strategy. We had a job which did start at each polling interval. The change log of the build always said "no changes", but the polling log showed that an external had changes which triggered the build.
After further investigation, be discovered that the working copy had a lock on an external.
Because the update of the external will be skipped, the SVN server always has a newer version available, which will trigger a build at the next polling interval.