-
Bug
-
Resolution: Unresolved
-
Major
-
None
We have a job with a lot of SVN modules configured (most of them point in fact to the same repository, but different paths in it) and the SVN post-commit-hook configured as described in the Wiki https://wiki.jenkins-ci.org/display/JENKINS/Subversion+Plugin#SubversionPlugin-Postcommithook
What we experienced by this was that we had often inconsistent checkouts - i.e. some modules having an older revision than others, though they are from the same repository. We had this on nearly every 3rd build!
We thought that Jenkins was always checking out based on the timestamp of the build to ensure consistent revision across all modules, however this turned out to be only partly true. What turned out to be the problem, is the ?rev=$REV parameter in the post-commit-hook which 'fixes' the modules (via RevisionParameterAction) which are triggered by this hook to be on that revision. In case some other changes come on to this module or other modules between starting the build and checking out the module, this lead to inconsistent checkouts as the other modules (not triggered explicitly) are checked-out based on timestamp.
The workaround in this case was quite simple: remove ?rev=$REV from the post-commit-hook. However, I think this points out a general problem when working with post-commit-hook/RevisionParameters and multiple modules.
Not sure how to fix this, but the description in the wiki should be adapted to remove ?rev=$REV from the example or at least issue a warning that it can lead to problems with multiple modules.
Also we could issue a warning in the build log if a job has multiple modules AND more than one of those have SVN changes AND only SOME of them have a revisionparameter specified.
For a general solution on how to ensure consistent checkouts, if only some modules have revisionparameter: I think that would be very difficult.